0

I have an apache web server, with mod_ssl & SSL certificates from letsencrypt. certbot reports they are fine and not expiring. A few different (of my many users) report that they get invalid/expired SSL certs from the server (and I have see output from wget from them to prove that).

To debug this, I want to log lots of details of each SSL connection. I would like to log, for each SSL connection the remote IP, and details about the SSL connection (e.g. protocol), the client provided SNI (server name identification) value, and then what SSL certificate/chain/key on the server was used. I want to

With ErrorLog ssl:traceN (for various N) I can get some of these details. But I cannot see what SSL certificate the server is using for each connection. How can I do this?

Improve this question
3
  • wget is not the best way to check certificate. Learn how to use openssl s_client tool, which was designed just for SSL/TLS debugging purposes. Commented Oct 26, 2021 at 10:28
  • I am not using wget to check the SSL cert. I do use openssl s_client for monitoring. However some of my users are using wget to download files, and they encounter this error, and have emailed me the terminal output. Commented Oct 26, 2021 at 10:36
  • 1
    It could well be their wget uses old ca_certificates database which doesn't include the new Let's Encrypt root certificate or some others. That's why their wget complains. If that's the case, you can't do and shouldn't do anything, it is their side which must be fixed. Commented Oct 26, 2021 at 10:42

2 Answers 2

Reset to default
1

mod_ssl exports a bunch of environment variables (see the list here), which can be used to log info about the certificate, for example, in a LogFormat directive like this:

LogFormat "cert_CN='%{SSL_SERVER_S_DN_CN}e', cert_expires='%{SSL_SERVER_V_END}e', vhost='%{Host}i', client='%h'" ssl_combined

However, before you start logging, be sure you check this article about expiring the DST Root CA X3 certificate. It is the one which signed the root CA of Let's Encrypt, and it has expired in September. However, the root CA of Let's Encrypt is accepted as a trusted CA in itself by virtually every system. For this, the expiration is not a problem, and the issued certificates continue to work, except for older systems using openssl version < 1.1.0, which does not stop the validation when a trusted CA found, but insists to check the whole chain (and fails).

If the system in question has an older openssl, you can do nothing about the problem on the server side, openssl should be upgraded on the client. If that is not an option, blacklisting the expired certificate helps.

Improve this answer
3
  • yes, I wonder if the letsencrypt cert change is relevant here Commented Oct 26, 2021 at 11:49
  • 1
    Again, if the old openssl or old ca_certificates problem exists on the client, nothing you can do on the server side. Educate your users, explain them why using outdated software is bad, why updates are necessary. Commented Oct 26, 2021 at 12:01
  • Yes I presume it's LE's change. But I want to be 100% sure. Commented Nov 8, 2021 at 9:01
1

Apache HTTPD's mod_ssl sets various environment variables, some of which could be used to identify the server certificate. For example, there are SSL_SERVER_CERT (a complete PEM-encoded cert), SSL_SERVER_S_DN (a DN of the subject), SSL_SERVER_M_SERIAL (a cert serial number).

You can use them in the logging configuration:

CustomLog "logs/ssl_request_log" "... %{SSL_SERVER_S_DN}x ..."

Read mod_ssl manual for details.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.