2
  • I have the guest's HTTPS port set to 443 on it's Apache 2 installation.
  • In Vagrantfile
    • I have vm.forwarded_port set to forward from 443 to 8443
    • I have vm.hostname set to actualdomain.org
  • I've also installed the vagrant plugin install vagrant-hostsupdater so that actualdomain.org is written to my hosts file, so it pulls up the developer environment and not the actual site when it is requested.
  • List item

    1. I ran vagrant connect...
    2. I ran vagrant share --https 443 --domain actualdomain.org but it reports the following:

    ==> default: Detecting network information for machine... default: Local machine address: 192.168.xx.10 default: Local HTTPS port: 443 ==> default: Checking authentication and authorization... ==> default: Creating Vagrant Share session... There was an error returned by the Vagrant Cloud server. The error message is shown below:

    • Domain cannot be used with this account

But if I run vagrant share without the --domain parameter, I end up with the following in my logs when I try to contact the site remotely:

Hostname XXXXX-YYY-ZZZZ provided via SNI and hostname XXXXX-YYY-ZZZZ.vagrantshare.com provided via HTTP are different

And in the browser I am returned an HTTP 400 Bad Request.

Is there any easy way around this? It seems to me that this didn't happen the last time I used vagrant, and it seems as though there was something added to TLS that causes it to balk about the SNI error since then.

I even tried adding a server alias that was the same as the XXXXX-YYY-ZZZ.vagrantshare.com, and it still is giving me an issue; does that mean that I have to rebuild the certificate everytime the hashicorp URL changes if I want to show it off to somebody via their browser?

leeand00
  • 25,510
  • 39
  • 140
  • 297
  • Oh give me a break...why the down vote? – leeand00 Nov 15 '16 at 16:14
  • It seems that it doesn't currently work with Apache. I think Apache considers the SNI host vs HTTP host mismatch behaviour of `vagrant share` a browser bug, and returns a 400 error. Nginx seemingly doesn't care. https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI – Ryan Dec 01 '16 at 01:01

0 Answers0