-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTPS SNI via vagrant share #5493
Comments
I am sorry you are having problems with Vagrant Share. Could you please share your Vagrantfile and apache config? /cc @armon for any info on the share proxy side of things. |
Sure; the vagrantfile looks like:
And the relevant bit of the Apache config looks like:
both of which I think are fairly ordinary, and the forwarding works ok over HTTP for a similar Apache config on port 8080. An example of the exact error message is:
Thanks for looking into this. |
Are you able to provide a single Vagrantfile to reproduce this issue without Salt (perhaps just using the shell provisioner)? I am having difficulty reproducing this issue myself. |
It should be able to reproduce this issue if you have one main default vhost with ssl and *.vagrant-share.com as SNI ssl vhost. SNI check fails because of this issue: |
Temporary workaround: Use a custom domain. Downside: self-signed certs (and possibly "real" certs) cause trust warnings in most browsers and don't work from android apps. Further, the cert will probably mismatch (you'll have a cert for *.vagrantshare.com being offered to your users, which probably won't match your domain). |
Permanent workaround: use ngrok. |
Why is the domain part "vagrantshare.com" stripped from the SNI? I don't think the browser would do that (please correct me if I am wrong). I can only imagine that the vagrant-infrastructure has a misbehaving proxy in between. Is there any possibility/workaround to show an https:// vagrant box quickly with "vagrant share" to a client/co-worker? @emanb29 Setting up a custom domain still works? With the only limitation being another certificate? I'd like to ask before starting to configure. NB: the Vagrant docs at https://atlas.hashicorp.com/help/vagrant/shares should state the current restrictions with HTTPS to save others from the hassle! |
From my tests a while back, this issue appears to be Apache specific. Using vagrant share on an nginx machine should work. |
Yes, I can confirm. vagrant share with https over nginx works fine. |
Any plans to address this or anyone have a workaround for apache? |
FYI @sumnercreations, on one of my newer puphpet generated apache boxes, I no longer experience the SNI issue. |
@mikeyxkcd , could you share your Apache config (or provide repro steps) so the rest of us can see an example of what works? I am also currently experiencing this issue. |
@law this is my puphpet
You might need to delete your existing box, and destroy your current vagrant instance for the project (tell me if there's anything special about my config), goodluck! |
This still seems to be an issue in 1.8.7. Custom domains do solve the SNI/HTTP mismatch issue, but create a new issue of the mismatched SSL certificate for the custom domain. I agree with @jonaseberle that is seems to be a problem with the vagrant share handling of standard *.vagrantshare.com hosts. Apache2 considers that a browser bug and responds with a 400, but it seems Nginx lets it through. At any rate, there doesn't seem to be a valid case for the HTTP Host header not matching the SNI host. |
Hi there, Thanks for reporting this bug. I'm sure this was a real issue when originally reported (our fault for not looking sooner!) but there have been multiple Vagrant releases since the original report. I'm going to close this issue now and request you reopen the issue if you're still experiencing this problem. I'm sorry this wasn't looked at earlier Cheers! |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
When we try to use vagrant share to expose an HTTPS endpoint using Apache inside the virtualbox, the Apache serves a "400 Bad Request" response. From looking at our Apache error log inside the Vagrant box, it's complaining that the hostnames provided via SNI (eg wonkey-donkey-123) and the HTTP host header (eg wonkey-donkey-123.vagrantshare.com) are different (note the domain suffix on the HTTP host header which is missing on the SNI name).
We're using Apache 2.2.22 on Ubuntu 12.04.5.
The text was updated successfully, but these errors were encountered: