Thank you Michael for another detailed explanation. I tried disabling SSL and re-enabling it but it didn't seem to work; I didn't touch the LE stuff as we're not using those certs.
I realised later that I could have relied on the line that includes the *.conf files for mod_perl and mod_ssl, but my fault finding was showing they were not loading. Once httpd was back up and running I decided to stop fiddling. My httpd.conf file should now be back to normal and future updates should be fine. Hope so anyway. Appreciate your help and your comments. Regards, Richard -----Original Message----- From: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of Michael Stauber Sent: 03 March 2018 02:18 To: blueonyx@mail.blueonyx.it Subject: [BlueOnyx:21802] Re: Strange SSL Error Hi Richard, Please bear in mind that when you report issues, I *need* to know the BlueOnyx version. 5207R/5208R: Uses Apache 2.2 5209R: Uses Apache 2.4 Hence the configuration they use is also different. Both also exhibit different behavior to some of the same configuration directives. > Edited httpd.conf, added below the list of modules: > > LoadModule perl_module modules/mod_perl.so LoadModule ssl_module > modules/mod_ssl.so This shouldn't be needed, because these exact modules are loaded in separate Apache config files: mod_perl.so: /etc/httpd/conf.d/perl.conf mod_ssl.so: /etc/httpd/conf.d/ssl.conf Now I just had an issue where I accidentally prompted the SSL error. This was the scenario: 5207R with all YUM updates. Existing Vsite had LE-cert, which was supposed to be replaced with a GoDaddy cert valid for 3 years. The client had the certificate in a format that the GUI doesn't support, so he asked me to do the conversion of the certificate and to install it. Steps taken: In the GUI I went to that Vsite, SSL, "Let's Encrypt", disabled the auto-renewal and saved. Then I went to "Certificate Authorities" and removed the LE intermediate. Then I imported the textfile containing private and public key for the SSL certificate. Finally I imported the two GoDaddy intermediates. When accessing the Vsite in a browser via HTTPS, I got served the SSL certificate of the GUI and got the dreaded certificate mismatch. Apache restart: No change. Killed Apache, restarted it: No change. Verified /etc/httpd/conf/vhosts/siteX: Correct paths to key, cert and ca-cert. I manually checked /home/sites/<site>/certs/ and checked key, cert and ca-certs. The coincided exactly with what I had uploaded except for *one* difference: ca-certs had three intermediates in it! The GUI hadn't removed the LE intermediate. I removed that manually without using the GUI, restarted Apache again and then it worked. Next I went to https://www.ssllabs.com/ssltest/analyze.html and checked the domain in question. Now here is an interesting thing about the difference between Apache 2.2 and Apache 2.4 Vsites with SSL via SNI: If you check an Apache 2.2 Vsite (recall: This was on 5207R), then the check at SSLlabs will show: Certificate #1: RSA 4096 bits (SHA256withRSA) Which contains the details about that certificate. And below that it shows: Certificate #2: RSA 4096 bits (SHA256withRSA) No SNI Which contains the SSL cert for the server itself. In this case an LE certificate. If you check a Vsite on a 5209R you only get the "Certificate #1:" shown in the result. And no, it doesn't matter if this is the first Vsite with SSL on an IP or the second or third, because any Vsite with SSL will always be the second Vsite with SSL, as the primary IP is covered by the AdmServ SSL certificate in a dynamically generated <VirtualHost>-container that is always first in the configuration processing order. I didn't want to toy longer with a clients production server, so with granted consent I took the previously used LE-cert and intermediate as well as the new GoDaddy cert and intermediate to a 5207R test-box. Created a Vsite with the same name, imported first the LE cert and intermediate, removed the intermediate (worked fine this time!), replaced the LE cert with the Godaddy cert and installed the two Godaddy intermediates. I repeated these steps a few times. On my workstation I had adjusted /etc/hosts to point that domain to the IP of the test-server. In all cases that I tried to reproduce the problem it didn't manifest. Instead it always worked as intended. All in all: I'm not happy that the cause of the problem remains so elusive. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
