Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I am running Apache on a Linux server hosted by Linode.
The server is addressable using the subdomain li723-109.members.linode.com
I have also registered 2 domain names that point to the same IP address: lewlasher.com and outriders.org
The Apache server responds to URLs at 3 domains.
However, when I applied for the certificate, I neglected to include the Linode subdomain, because I was only interested in using HTTPS with the 2 domains that I registered.
3 questions:
Would it be simply (in terms of getting Apache to work) to get a certificate that includes the Linode subdomain?
If so, can I somehow amend the existing certificate to include the Linode subdomain, or should I delete the existing certificate and get a new one, or get a second certificate just for the Linode subdomain?
Do I need to configure Apache for SNI (Server Name Indication?)
I went ahead and revoked the old certificate (with 4 domains) and created a new certificate with all 5 domains.
I noticed now that certbot reported that the certificate is in the file named fullchain.pem ; I had been operating under the assumption that the certificate was in the file named cert.pem .
Now, I am typically getting ERR_SSL_PROTOCOL_ERROR errors from the browser on all domains.
This is almost never the right answer. The only reason to revoke a cert is if you believe the private key has been compromised.
That is not correct; the cert is (as you'd expected) in cert.pem; while fullchain.pem includes both your domains' cert and the intermediate signing certs. Which one you will need depends on your server; for your version of Apache, I think you'd want to separately call out cert.pem and chain.pem in your configuration.
But the problem right now is that your server is speaking http (not https) on port 443--that just isn't going to work.
As for the fullchain.pem vs. cert.pem question, the exact language from Certbot is as follows:
Certificate is saved at: /etc/letsencrypt/live/lewlasher.com/fullchain.pem
As for what the server is "speaking", I'm not sure what the basis is for saying that it is speaking HTTP. The Apache configuration, in each <VirtualHost *.433> block, has
SSLEngine on
SSLCertificateFile .... (either cert.pem or fullchain.pem, doesn't make a difference)
SSLCertificateKeyFile ... privkey.pem
Second thoughts about "Let's Debug didn't discover any errors" ...
If I ignore the sentence "All OK! in big letters, and go down to the smaller letters that say "Show verbose information", there is what appears to be an error, under the heading "LetsEncryptStaging". The "challenge" to create a ".well-known" subdirectory failed under each webroot, probably because the webroot directory is writeable only by root.
I changed the protections, but it looks like the test is failing because the ".well-known" subdirectories were not created, and it is no longer trying to create them.
No. A 404 error is expected since you do not have that file on your server. If it said "timeout" or something trying to reach your server that would be a problem.
It looks like you got a valid cert with all 5 domain names in it. See the Rate Limit section of the Let's Debug output.
But, you requested just CERTONLY so need to configure Apache correctly by hand. That is not working. The SSL Labs test cannot even reach your server using HTTPS (and neither can I).
UPDATE:
You could look at the Mozilla Configurator to help you with that. Enter the versions for openssl and others for best results. Then retry SSL Labs Server test until it works.
AH00526: Syntax error on line 3 of /etc/apache2/mods-enabled/ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/lewlasher.com/cert.pem' does not exist or is empty
(A little while ago, it was configured to use fullchain.pem, which gave the same error, so I reconfigured it to use cert.pem instead. Both files exist and are non-empty.)