MacOS ElCapitan Recent Renew now all sites fail

My domain is: myndex.com

I ran this command: visiting with Chrome or Safari, security warning states "certificate not valid" also, using:

What's My Chain Cert?

Gives the error:
TLS handshake error: error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type

My web server is (include version):

Apache 2.4
MacOS 10.11.6 (ElCapitan) with Server 5.2

I can login to a root shell: Yes

The version of my client: certbot 1.7.0

I am baffled. After renewing the certificates, and running the same exact commands as previous renewals, the sites all exhibit this error "invalid certificate"... When checking my chain, I get a collection of different responses, with the above error regarding handshake being both the most cryptic ro me, and also where I suspect the actual issue lies.

Everything seemed to be fine until this week.

Any thoughts are welcome at this point, Thank you.

Andy

1 Like

I took a look at your site with SSL Server Test: myndex.com (Powered by Qualys SSL Labs)

The thing that stands out to me is that your certificate chain seems to be misconfigured: Your webserver is serving a legitimate leaf certificate for myndex.com, but instead of serving the Let's Encrypt R3 intermediate along with it, there's a self-signed certificate for MyndexServer.myn

Your apache config should have something like this in it:

SSLCertificateFile /etc/letsencrypt/live/[dir]/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/[dir]/privkey.pem

Do you have something other than fullchain.pem as your SSLCertificateFile?

6 Likes

Still digging, I'm finding this error in the logs:

servermgr_certs[3995]: -[CertsRequestHandler(KeychainOpenSSLExport) exportIdentity:]: SecKeychainItemExport(certificateChain) no certificate chain available, defaulting to a leaf cert only

But I've confirmed I have all four files in the etc/certificates folder including the full chain.

The service needs to use the fullchain file (or a file with a chain in it).
[it doesn't just automatically work because the files are all placed into the folder]

4 Likes

In a moment of frustration, I reinstalled the server software, starting fresh with no sites BUT that did not fix this, but what did:

Problem was solved by:

Replacing the cert and the intermediate and root certs from the system keychain with a newly generated chain.

First:

Going to https://whatsmychaincert.com/
and creating a chain with root using one of the domains in the cert OTHER THAN myndex.com, as after first creating myndex.com as a site in the new, fresh server, was still getting the "handshake error".

The "WhatsMyChain..." website will not generate a chain with that error present. However, that error is NOT present in the default site (???) (handshake is separate issue I need to track down).

Second:

After generating the cert chain including root, and after deleting all the related certs including the intermediate and root, I installed the newly generated/corrected chain file into the system keychain.

Then restarted the HTTPD and viola, it works with no "invalid cert" error.

SEPARATE: there is still the handshake error, but at least, sites are now working again.

TAKEAWAY: I have reason to believe the problem here relates to how MacOS handles the keychain(s) and that earlier attempts to solve this resulted in an ISRG X1 root being installed that was causing a conflict. This was (I believe) due to an ISRG root with an expiration of 2025 existing in the keychain. The ISRG root now installed expires 2035.

Thank you for the helpful comments.

"Legacy" OSX, through I think 10.14, have an issue with the Long chain because the expired ISRG Root X1 is in their Trust Store. For most platform versions affected by this, the easiest fix is to just remove the X1 certificate from the Keychain Access and OpenSSL trust stores.

4 Likes

Yes, this is how it seems, the confusing part is that the problematic ISRG Root X1 has an expiration date in 2025, so it is not-intuitive that that is the problem cert.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.