Went to fix a small error with LetsEncrypt not auto-renewing - has now turned into a huge project where all of my website are now completely down and not working.
@peppers Welcome to this community for your first post!
The certificate should include all of the domain names in a single VirtualHost. You have both your apex domain and www name in the same VHost so your cert needs both names.
To combine both names on the same cert, do something like:
You only need one certbot command for this - not one for each domain name.
That said, it is much easier to assist when you complete the answers to the form you were shown when starting a post in the Help topic. Hopefully this is enough to resolve your situation. If not, it would be helpful if you provided at least the actual domain names. Thanks
This did not work. I'm still getting ERR_SSL_PROTOCOL_ERROR in the browser.
I am not seeing the "AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name" in the apache logs though.
Ubuntu 20.04
apache2 -v
Server version: Apache/2.4.41 (Ubuntu)
Server built: 2021-10-14T16:24:43
sudo certbot --version
certbot 0.40.0
Can login on root shell: yes. Have about 30 websites in VirtualHost
I cannot help further without your actual domains. And, I'm about to be offline for the night soon anyway. Maybe another volunteer will take over.
Until then, you could check your site with these websites for clues. That way you do not have to share your domain name. You could also search this forum for that error message.
I also question your need for the --installer Apache. From your sample config it looks like you already have SSL configured. You do not need to do it again. Also, after certbot installs (configures) your apache it marks lines as "managed by certbot". You do not show those so I have to guess you updated your conf manually. If this is the case, you could change your certbot command to this - although I do not think this will resolve your protocol error.
sudo apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 is a NameVirtualHost
default server localhost (/etc/apache2/sites-enabled/000-default.conf:2)
port 80 namevhost localhost (/etc/apache2/sites-enabled/000-default.conf:2)
port 80 namevhost www.someotherwebsite.com (/etc/apache2/sites-enabled/someotherwebsite.com.conf:1)
alias someotherwebsite.com
[ .... 30+ other websites with same setup ]
port 80 namevhost www.example.com (/etc/apache2/sites-enabled/example.com.conf:10)
alias example.com
*:443 is a NameVirtualHost
default server www.someothersite.com (/etc/apache2/sites-enabled/someothersite.com.conf:11)
port 443 namevhost www.someothersite.com (/etc/apache2/sites-enabled/someothersite.com.conf:11)
[ .... 30+ other websites with same setup ]
port 443 namevhost www.example.com (/etc/apache2/sites-enabled/example.conf:20)
alias example.com
Wow! You aren't even willing to put the effort into hiding the names individually.
search and replace "RealName1" with "FakeName1"
search and replace "RealName2" with "FakeName2"
search and replace "RealName3" with "FakeName3"
...
search and replace "RealName30" with "FakeName30"
If there is a problem in there, you have just erased it with:
Let's hope it's not there (as we look elsewhere)...
How about the output of: certbot certificates
[this output you can reduce to only the cert(s) that have any of the names "example.com" or "www.example.com" - the rest are irrelevant]
Not much to worry about there.
The "default" is what gets served when SNI can't match the requested name.
If a vhost config isn't defined/labeled as "default", then Apache will simple take the first one found.
["first" here being the first such type encountered after including the main config and an alpha-numerically sorted list of included files]
That depends on your definition.
I find very little about Apache "normal".
WebserverMisconfiguration
ERROR
www.example.com's webserver may be misconfigured.
Web server is serving the wrong protocol on the wrong port: Get "https://www.example.com/.well-known/acme-challenge/letsdebug-test": http: server gave HTTP response to HTTPS client. This may be due to a previous HTTP redirect rather than a webserver misconfiguration.
Trace:
@0ms: Making a request to http://www.example.com/.well-known/acme-challenge/letsdebug-test (using initial IP ***.***.***.***)
@0ms: Dialing ***.***.***.***
@18ms: Server response: HTTP 301 Moved Permanently
@18ms: Received redirect to https://www.example.com/.well-known/acme-challenge/letsdebug-test
@18ms: Dialing ***.***.***.***
@37ms: Experienced error: tls: first record does not look like a TLS handshake
Challenge failed for domain example2.com
Challenge failed for domain www.example2.com
http-01 challenge for example2.com
http-01 challenge for www.example2.com
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: example2.com
Type: connection
Detail: Fetching
https://www.example2.com/.well-known/acme-challenge/izR5ZAfNRcGFddkptbNOmBbZrdy0ijC87XmlHFSR0XE:
Error getting validation data
Domain: www.example2.com
Type: connection
Detail: Fetching
https://www.example2.com/.well-known/acme-challenge/fYQCdL1WBWOir-QcBiu20EglPwZrb_one1MUnDSbu38:
Error getting validation data
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
Everything was working fine earlier today, but LetsEncrypt did something that wrecked the server.
I'm having a hard time following that logic.
Your requests are for certonly
Such requests wouldn't change anything in your Apache config.
But you fail to show the config, so I really can't be sure of anything - more than you don't want to take any part of the "blame" (you seem to be throwing around).
Take a good look.
Four eyes are usually better than two...
But with your hands over mine, we're back with only two eyes - the same two that missed the mistake. How is your HTTP vhost config handling the challenge requests? How/why are they being redirected? How are they being handled after the redirection?
That seems to have gotten everything working again. Not sure why everything worked fine for months, and then everything breaks trying to fix the auto-renewal. One thing is for sure, I've never messed around with the ssl.conf file before. Most likely, it was probably some kind of error I made, LetsEncrypt allowed it to work for months, and then when LetsEncrypt made some slight changes on their end, everything broke.
I greatly appreciate your help Rudy and Mike for taking the time to work with me.
But, won't these changes get overwritten the next time you update Apache?
I am also puzzled why adding a default VHost would resolve it but given you are unwilling to share your config or domain names there is not much more that we can do.
It's like an intended unintentional mishap that just happens to get Apache to do what was "expected".
"This" will eventually resurface.
Changing the "default" means it is missing a SNI match and being forced to serve "it" via "default".
Apache is notorious for running at all costs.
Don't get me wrong, I do use Apache.
But I set my bar very low and expect things to go off track with it, so I build a very sturdy track even it can't derail. And I get my desired result.
If you set a very high bar and expect it to do things (right) for you by building a very flimsy track, it will go anywhere it wants and may sometimes end up where you wanted it to - but that is called "sheer luck".
