[BlueOnyx:21803] Re: Strange SSL Error

[Gerrit Haas]

Hi all,
we had also a few customers complaining about this issue.

The way, you can always resolve is
- change something in the PHP settings on the server side. (not in the site tab) - E.g. increase max_upload_filesize.
This will result in all config / vhost config files to be rewritten.
-restart httpd (service httpd restart) 
Sometimes it did require a whole server restart.

Last case was a 5209R with a multidomain cert.


Mit freundlichen Grüßen aus Bad Vilbel
Gerrit Haas


-----------------------------------------------
blackpoint GmbH - Friedberger Straße 106b - 61118 Bad Vilbel
Systemadministrator
Tel.: +49 6101 65788 32
IT-Support: +49 6101 65788 - 30
Fax: +49 6101 65788 99
eMail: Gerrit.Haas at blackpoint.de

Tel. Rufbereitschaft (Außerhalb der Arbeitszeiten) +49 6101 65788-40

Vertretungsberechtigt Dirk Estenfeld und Mario Di Rienzo HRB 50093 Frankfurt am Main USt.-IdNr. de210106871

Besuchen Sie uns im Internet unter http://www.blackpoint.de
Problemlos Domains registrieren: http://www.edns.de
Einfach und günstig Daten sichern: https://www.blackpoint.de/produkte/hosting/weitere-cloud-dienste/veeam-cloud-connect/



Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
-----------------------------------------------

-----Ursprüngliche Nachricht-----
Von: Blueonyx [mailto:blueonyx-bounces at mail.blueonyx.it] Im Auftrag von Michael Stauber
Gesendet: Samstag, 3. März 2018 03:18
An: blueonyx at mail.blueonyx.it
Betreff: [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 at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx