Maybe in VirtualBox enabled the “Only-host” (instead “bridged networking”) for guest OS…
Did you ever figure this out? Has anyone got this working with Apache yet?
Update: I just discovered that if I switch my ports.conf from Listen IP:443 to Listen 443 that seemed to fix it
Start SSL. Too many bugs here.
Dunno about that. It’s pretty straightforward to do the basics that every other certificate issuer requires. It’s when you want to get fancy with automated setup that issues show up. Understandable, since not everyone uses an identical setup. In my case, the “webroot” auth method with the main client worked great. Even if that didn’t work, the manual setup would be equivalent to what every other issuer has required/offered.
Also, StartSSL Class 1 (free) is only free for non-commercial uses. If you want to use their certificates for a business to make profit, they require a Class 2 at minimum.
The documentation here is not straightforward. There are better alternatives that are proven and not as much a hassle.
Well, it's a lot of new technology in place, so it's going to be a bit of a rough patch getting everything working in a polished manner. The closed beta and the open staging/testing has all been about reducing the pain points for as many cases as possible before opening up to the public.
Even if you don't like the main client, there are other options. Even if those don't help, it's easy enough to manually submit the request and validate it just like every other issuer.
Anyway, nobody is forcing you to use the service, so use what is comfortable for you.
Do you work for/on letsencrypt?
No, just a "normal" user. I believe LE staff have a special badge next to their name.
How can you go live when it doesn’t work with Ubuntu 14.04 Apache 2.4.7?
./letsencrypt-auto --apache
fails as described in this thread
./letsencrypt-auto certonly --manual
has failed 5 times with 404, but because the strings are so long it is impossible to check I have set it up correctly. Why make it so unmanageable? Four characters would be enough.
Couldn’t you have done a GUI for this instead of the error-prone terminal with its hateful copy-paste functionality?
Documentation says that it currently only works with Debian. Ubuntu is probably just different enough for it to not work properly.
The long string is a hash of a special token. You can test it well enough by copying and pasting the URL as described in the manual instructions.
If you are having issues, try working on the staging server to make sure you don't run into certificate rate limiting for the production server.
There are several third-party client implementations you can try out if you want something simpler. I'm sure someone will make a point-and-click solution eventually.
Actually what you have to do is: in the terminal, highlight the data string and Edit >Copy, then switch to an editor and New > Paste, then Save As, then back to the terminal and highlight the file part of the URL, Edit > Copy, back to the editor and Paste in the filename, Save. Then to check its there, back to the terminal, highlight the whole URL, Edit > Copy, switch to a browser and Paste.
And then the browser finds it 200 OK. Great, now back to the terminal and hit ENTER, and the verification process does the same thing and … nothing. /var/log/apache2/access.log shows me getting the 200 OK, but nothing from anyone else.
Aha, you say, the DNS records aren’t pointing at the correct IP, but they are. Everybody in the world can find my domain except the verifying agent. 
I’ve done it 10 times now
Did you ever figure this out? Has anyone got this working with Apache yet?
Update: I just discovered that if I switch my ports.conf from Listen IP:443 to Listen 443 that seemed to fix it
This seems to be the same issue I'm having, however I have multiple IPs and that webserver I only want listening on one of them. The port is in use by different programs on different IPs... Not sure how to automate this.