Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check with clientcert will fail when chainfile is missing #525

Open
dhoffend opened this issue Nov 11, 2024 · 4 comments
Open

Check with clientcert will fail when chainfile is missing #525

dhoffend opened this issue Nov 11, 2024 · 4 comments
Assignees
Labels

Comments

@dhoffend
Copy link

Describe the bug

When you run a check with a client certificate against a tls secured secured service, but your client certificate requires a chain file, the check will fail with sslv3 alert bad certificate. The openssl s_client doesn't suppurt respect the certificate chain in a bundle, but rather requires the -chainCAfile commandline parameter.

To Reproduce

Create a Root and Intermediate CA, sign the client certificate with the intermediate CA. Run checks.

Expected behavior

Request should work out of the box

System:

  • OS: Debian/Linux
  • OS version: 11
  • check_ssl_cert version: 2.85.0
  • OpenSSL version (openssl version): OpenSSL 1.1.1w

Additional context/output

/tmp/check_ssl_cert -H <ip> -p <port> -w 45 -c 21 -P https --ignore-ocsp --ignore-sct --ignore-host-cn --clientcert ~/etc/ssl/monitoring.bundle.crt --clientkey ~/etc/ssl/monitoring.key 
SSL_CERT CRITICAL <ip>:<port>: SSL error: 140576803779904:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1562:SSL alert number 42|days_chain_elem1=1090;45;21;; days_chain_elem2=1944;45;21;; 

Test with plain openssl

without chain:

openssl s_client -cert ~/etc/ssl/monitoring.bundle.crt -key ~/etc/ssl/monitoring.key -connect <ip>:<port> < /dev/null
[...]
Verify return code: 0 (ok)
---
140425664640320:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1562:SSL alert number 42

with chain:

openssl s_client -cert ~/etc/ssl/monitoring.crt -key ~/etc/ssl/monitoring.key -chainCAfile ~/etc/ssl/monitoring.chain.crt -connect <ip>:<port> < /dev/null
[...]
Verify return code: 0 (ok)
---
DONE

Solution

Either provide a --clientchainfile commandline option or set -cert and -chainCAfile to the same value. That actually works

--- check_ssl_cert.orig	2024-11-11 20:57:31.370182820 +0100
+++ check_ssl_cert	2024-11-11 20:58:16.498064823 +0100
@@ -5898,7 +5898,7 @@
 
     CLIENT=""
     if [ -n "${CLIENT_CERT}" ]; then
-        CLIENT="-cert ${CLIENT_CERT}"
+        CLIENT="-cert ${CLIENT_CERT} -chainCAfile ${CLIENT_CERT}"
     fi
     if [ -n "${CLIENT_KEY}" ]; then
         CLIENT="${CLIENT} -key ${CLIENT_KEY}"
@dhoffend dhoffend added the bug label Nov 11, 2024
@matteocorti matteocorti self-assigned this Nov 11, 2024
@matteocorti
Copy link
Owner

Thanks for the report. I actually added the client cert feature, but I never used it (so it's difficult to detect problems).

@matteocorti
Copy link
Owner

The option -chainCAfile is only available from OpenSSL 3.0. I'll implement the fix but I have to think what to do with older versions ...

@dhoffend
Copy link
Author

The option -chainCAfile is only available from OpenSSL 3.0. I'll implement the fix but I have to think what to do with older versions ...

As I used the -chainCAfile option with openssl 1.1.1w on Debian 11. I would assume that it could work. And when you use this as an optional commandline parameter for check_ssl_cert , then people can decide weither they wanna use it or not.

@dhoffend
Copy link
Author

dhoffend commented Nov 12, 2024

On the other hand, when you only want to monitor the expiration date and state of the remote certificate, we could simply ignore the "bad certificate alarm" with something like --ignore-clientcert.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants