[BlueOnyx:21802] Re: Strange SSL Error

[Michael Stauber]

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