Hi!
After "playing" significant time with certificate authentication, I managed to authenticate one user. However when I tried to authenticate a different user with a similar certificate, I see a
TLS trace: SSL3 alert read:fatal:unsupported certificate
Error. Can I can some details about the "usupportedness" of my certificate? The only thing I could think if is that uid of the newer certificate has a CN that is three characters longer than the one that worked.
A more complete trace for ldapwhoami woul look like this: ... ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 2, err: 0, subject: /.... Root-CA (2018), issuer: /... Root-CA (2018) TLS certificate verification: depth: 1, err: 0, subject: /... Host-CA (2018), issuer: /... Root-CA (2018) TLS certificate verification: depth: 0, err: 0, subject: /... FQHN, issuer: /... Host-CA (2018) TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write certificate verify TLS trace: SSL_connect:SSLv3/TLS write finished ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_int_sasl_open: host=FQHN SASL/EXTERNAL authentication started ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 26 bytes to sd 3 ldap_msgfree ldap_result ld 0x56432476ac30 msgid 2 wait4msg ld 0x56432476ac30 msgid 2 (infinite timeout) wait4msg continue ld 0x56432476ac30 msgid 2 all 1 ** ld 0x56432476ac30 Connections: * host: FQHN port: 389 (default) * from: IP=172.20.16.36:57868 refcnt: 2 status: Connected last used: Wed Mar 5 15:42:03 2025
** ld 0x56432476ac30 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x56432476ac30 request count 1 (abandoned 0) ** ld 0x56432476ac30 Response Queue: Empty ld 0x56432476ac30 response count 0 ldap_chkResponseList ld 0x56432476ac30 msgid 2 all 1 ldap_chkResponseList returns ld 0x56432476ac30 NULL ldap_int_select read1msg: ld 0x56432476ac30 msgid 2 all 1 ber_get_next TLS trace: SSL3 alert read:fatal:unsupported certificate ber_get_next failed, errno=0. ldap_err2string ldap_sasl_interactive_bind: Can't contact LDAP server (-1) ...
Kind regards, Ulrich Windl
On Wed, Mar 5, 2025 at 9:53 AM Windl, Ulrich u.windl@ukr.de wrote:
After „playing“ significant time with certificate authentication, I managed to authenticate one user. However when I tried to authenticate a different user with a similar certificate, I see a
TLS trace: SSL3 alert read:fatal:unsupported certificate
Error. Can I can some details about the “usupportedness” of my certificate? The only thing I could think if is that uid of the newer certificate has a CN that is three characters longer than the one that worked.
Have a look at the cert using OpenSSL and the x509 subcommand:
$ openssl x509 -in .../rsyslog/contrib/gnutls/ca.pem -inform PEM -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C = DE, O = rsyslog test root CA, OU = CA, CN = rsyslog-test-root-ca Validity Not Before: May 20 12:58:12 2008 GMT Not After : May 18 12:58:24 2018 GMT Subject: C = DE, O = rsyslog test root CA, OU = CA, CN = rsyslog-test-root-ca Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c3:6b:3e:57:e5:82:2b:b8:f1:f4:c2:e9:0c:3e: 29:3b:c4:82:aa:ae:90:9c:af:c1:a6:db:ca:33:e6: 1e:06:b5:7d:b9:dd:e5:ab:a6:20:6e:93:66:bf:7f: f0:8a:0e:37:ae:aa:68:96:a9:3b:3d:d0:f1:4d:6f: e6:75:73:e6:33:bd:a8:2a:bf:cd:15:cd:9c:03:23: 84:5c:af:09:4d:68:aa:c1:cf:ff:57:8a:8c:02:72: 85:7c:b3:b1:af:57:6b:ed:64:43:d2:4e:13:73:cf: 81:58:93:10:8c:bd:b3:98:65:e2:48:61:05:61:66: 08:14:72:e6:9d:7e:19:83:23 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 33:61:04:20:52:6D:18:2C:D7:5A:AC:99:DC:D9:CD:4B:C5:85:42:94 Signature Algorithm: sha1WithRSAEncryption Signature Value: b8:65:ad:1f:b2:64:a5:ad:27:fe:2c:ea:43:97:5d:0d:03:ff: 2d:3e:ad:6a:2b:c2:c2:5a:44:60:45:3d:6a:e9:a9:40:f5:96: c6:d6:32:c0:a6:8f:45:f3:35:25:33:0b:02:26:1d:f0:c4:bb: 4c:9f:13:61:1b:ef:47:7d:98:d3:66:3e:3a:15:e7:d7:5c:44: 46:45:af:05:3d:8c:f7:2c:ea:5f:a8:43:7d:1b:9e:37:b4:53: 7c:f5:ac:7e:6f:cd:05:35:68:8f:38:da:10:27:13:15:e9:d9: 89:de:cf:0b:92:62:15:b7:14:e8:f4:94:31:9e:3d:fc:93:e1: c4:0a
A more complete trace for ldapwhoami woul look like this:
…
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS read server hello
TLS trace: SSL_connect:TLSv1.3 read encrypted extensions
TLS trace: SSL_connect:SSLv3/TLS read server certificate request
TLS certificate verification: depth: 2, err: 0, subject: /…. Root-CA (2018), issuer: /… Root-CA (2018)
TLS certificate verification: depth: 1, err: 0, subject: /… Host-CA (2018), issuer: /… Root-CA (2018)
TLS certificate verification: depth: 0, err: 0, subject: /… FQHN, issuer: /… Host-CA (2018)
TLS trace: SSL_connect:SSLv3/TLS read server certificate
TLS trace: SSL_connect:TLSv1.3 read server certificate verify
TLS trace: SSL_connect:SSLv3/TLS read finished
TLS trace: SSL_connect:SSLv3/TLS write change cipher spec
TLS trace: SSL_connect:SSLv3/TLS write client certificate
TLS trace: SSL_connect:SSLv3/TLS write certificate verify
TLS trace: SSL_connect:SSLv3/TLS write finished
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_int_sasl_open: host=FQHN
SASL/EXTERNAL authentication started
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 26 bytes to sd 3
ldap_msgfree
ldap_result ld 0x56432476ac30 msgid 2
wait4msg ld 0x56432476ac30 msgid 2 (infinite timeout)
wait4msg continue ld 0x56432476ac30 msgid 2 all 1
** ld 0x56432476ac30 Connections:
host: FQHN port: 389 (default)
from: IP=172.20.16.36:57868
refcnt: 2 status: Connected
last used: Wed Mar 5 15:42:03 2025
** ld 0x56432476ac30 Outstanding Requests:
msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
ld 0x56432476ac30 request count 1 (abandoned 0)
** ld 0x56432476ac30 Response Queue:
Empty
ld 0x56432476ac30 response count 0
ldap_chkResponseList ld 0x56432476ac30 msgid 2 all 1
ldap_chkResponseList returns ld 0x56432476ac30 NULL
ldap_int_select
read1msg: ld 0x56432476ac30 msgid 2 all 1
ber_get_next
TLS trace: SSL3 alert read:fatal:unsupported certificate
ber_get_next failed, errno=0.
ldap_err2string
ldap_sasl_interactive_bind: Can't contact LDAP server (-1)
…
Jeff
Jeffrey,
thanks! Actually that's what I did: Comparing the data of the certificate that worked with that which does not. I could not find any relevant difference.
I also wondered whether the objectclass might make a difference: The object that works has: objectClass: top objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount
and the object that doesn't has objectClass: account objectClass: simpleSecurityObject
Both objects are in the same DIT (database), but have a different context. However I adjusted the olcAuthzRegexp: olcAuthzRegexp: {0} "^cn=uid\3Dsyncrepl,...,c=DE$" "dn: uid=syncrepl,ou=system,....,dc=de" olcAuthzRegexp: {1} "^cn=uid\3D([^,]+),...,c=DE$" "dn: uid=$1,ou=people,...dc=de"
The "..." is an ellipsid (redacted some details). The second regex is the one that works...
Kind regards, Ulrich Windl
-----Original Message----- From: Jeffrey Walton noloader@gmail.com Sent: Wednesday, March 5, 2025 4:17 PM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Getting details for "TLS trace: SSL3 alert read:fatal:unsupported certificate"
On Wed, Mar 5, 2025 at 9:53 AM Windl, Ulrich u.windl@ukr.de wrote:
After „playing“ significant time with certificate authentication, I managed to
authenticate one user. However when I tried to authenticate a different user with a similar certificate, I see a
TLS trace: SSL3 alert read:fatal:unsupported certificate
Error. Can I can some details about the “usupportedness” of my certificate?
The only thing I could think if is that uid of the newer certificate has a CN that is three characters longer than the one that worked.
Have a look at the cert using OpenSSL and the x509 subcommand:
$ openssl x509 -in .../rsyslog/contrib/gnutls/ca.pem -inform PEM -text - noout Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C = DE, O = rsyslog test root CA, OU = CA, CN = rsyslog-test-root-ca Validity Not Before: May 20 12:58:12 2008 GMT Not After : May 18 12:58:24 2018 GMT Subject: C = DE, O = rsyslog test root CA, OU = CA, CN = rsyslog-test-root-ca Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c3:6b:3e:57:e5:82:2b:b8:f1:f4:c2:e9:0c:3e: 29:3b:c4:82:aa:ae:90:9c:af:c1:a6:db:ca:33:e6: 1e:06:b5:7d:b9:dd:e5:ab:a6:20:6e:93:66:bf:7f: f0:8a:0e:37:ae:aa:68:96:a9:3b:3d:d0:f1:4d:6f: e6:75:73:e6:33:bd:a8:2a:bf:cd:15:cd:9c:03:23: 84:5c:af:09:4d:68:aa:c1:cf:ff:57:8a:8c:02:72: 85:7c:b3:b1:af:57:6b:ed:64:43:d2:4e:13:73:cf: 81:58:93:10:8c:bd:b3:98:65:e2:48:61:05:61:66: 08:14:72:e6:9d:7e:19:83:23 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 33:61:04:20:52:6D:18:2C:D7:5A:AC:99:DC:D9:CD:4B:C5:85:42:94 Signature Algorithm: sha1WithRSAEncryption Signature Value: b8:65:ad:1f:b2:64:a5:ad:27:fe:2c:ea:43:97:5d:0d:03:ff: 2d:3e:ad:6a:2b:c2:c2:5a:44:60:45:3d:6a:e9:a9:40:f5:96: c6:d6:32:c0:a6:8f:45:f3:35:25:33:0b:02:26:1d:f0:c4:bb: 4c:9f:13:61:1b:ef:47:7d:98:d3:66:3e:3a:15:e7:d7:5c:44: 46:45:af:05:3d:8c:f7:2c:ea:5f:a8:43:7d:1b:9e:37:b4:53: 7c:f5:ac:7e:6f:cd:05:35:68:8f:38:da:10:27:13:15:e9:d9: 89:de:cf:0b:92:62:15:b7:14:e8:f4:94:31:9e:3d:fc:93:e1: c4:0a
A more complete trace for ldapwhoami woul look like this:
…
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:SSLv3/TLS read server hello
TLS trace: SSL_connect:TLSv1.3 read encrypted extensions
TLS trace: SSL_connect:SSLv3/TLS read server certificate request
TLS certificate verification: depth: 2, err: 0, subject: /…. Root-CA (2018),
issuer: /… Root-CA (2018)
TLS certificate verification: depth: 1, err: 0, subject: /… Host-CA (2018),
issuer: /… Root-CA (2018)
TLS certificate verification: depth: 0, err: 0, subject: /… FQHN, issuer: /…
Host-CA (2018)
TLS trace: SSL_connect:SSLv3/TLS read server certificate
TLS trace: SSL_connect:TLSv1.3 read server certificate verify
TLS trace: SSL_connect:SSLv3/TLS read finished
TLS trace: SSL_connect:SSLv3/TLS write change cipher spec
TLS trace: SSL_connect:SSLv3/TLS write client certificate
TLS trace: SSL_connect:SSLv3/TLS write certificate verify
TLS trace: SSL_connect:SSLv3/TLS write finished
ldap_sasl_interactive_bind: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_int_sasl_open: host=FQHN
SASL/EXTERNAL authentication started
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 26 bytes to sd 3
ldap_msgfree
ldap_result ld 0x56432476ac30 msgid 2
wait4msg ld 0x56432476ac30 msgid 2 (infinite timeout)
wait4msg continue ld 0x56432476ac30 msgid 2 all 1
** ld 0x56432476ac30 Connections:
host: FQHN port: 389 (default)
from: IP=172.20.16.36:57868
refcnt: 2 status: Connected
last used: Wed Mar 5 15:42:03 2025
** ld 0x56432476ac30 Outstanding Requests:
msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
ld 0x56432476ac30 request count 1 (abandoned 0)
** ld 0x56432476ac30 Response Queue:
Empty
ld 0x56432476ac30 response count 0
ldap_chkResponseList ld 0x56432476ac30 msgid 2 all 1
ldap_chkResponseList returns ld 0x56432476ac30 NULL
ldap_int_select
read1msg: ld 0x56432476ac30 msgid 2 all 1
ber_get_next
TLS trace: SSL3 alert read:fatal:unsupported certificate
ber_get_next failed, errno=0.
ldap_err2string
ldap_sasl_interactive_bind: Can't contact LDAP server (-1)
…
Jeff
On Wed, 5 Mar 2025, Windl, Ulrich wrote:
thanks! Actually that's what I did: Comparing the data of the certificate that worked with that which does not. I could not find any relevant difference.
The error being reported is from the OpenSSL library, not from OpenLDAP itself. The certs, or some CA the failing cert would chain through, are different in some way that _is_ relevant.
Philip Guenther
Hi!
I used "openssl verify" to verify both certificates, using both, -CApath and -CAfile, and both certificates were "OK". I ran those commands as "root", but I also verified that certificate and key can be read as "ldap".
Kind regards, Ulrich Windl
-----Original Message----- From: Philip Guenther pguenther@proofpoint.com Sent: Thursday, March 6, 2025 8:48 AM To: Windl, Ulrich u.windl@ukr.de Cc: noloader@gmail.com; openldap-technical@openldap.org Subject: [EXT] RE: Re: Getting details for "TLS trace: SSL3 alert read:fatal:unsupported certificate"
On Wed, 5 Mar 2025, Windl, Ulrich wrote:
thanks! Actually that's what I did: Comparing the data of the certificate that
worked with that which does not.
I could not find any relevant difference.
The error being reported is from the OpenSSL library, not from OpenLDAP itself. The certs, or some CA the failing cert would chain through, are different in some way that _is_ relevant.
Philip Guenther
Digging further into it, I noticed that ther openssl command used to verify was " OpenSSL 3.1.4 24 Oct 2023 (Library: OpenSSL 3.1.4 24 Oct 2023)", but /usr/sbin/slapd is linked to libssl.so.1.1
Both certificates have "Public-Key: (2048 bit)", but I noticed that the "X509v3 extensions" are different. Maybe that's the problem.I'll re-create the certificate and see what happens. Anyway hunting for these type of problems is not much fun..
Kind regards, Ulrich Windl
-----Original Message----- From: Windl, Ulrich u.windl@ukr.de Sent: Thursday, March 6, 2025 12:03 PM To: Philip Guenther pguenther@proofpoint.com Cc: noloader@gmail.com; openldap-technical@openldap.org Subject: [EXT] RE: RE: Re: Getting details for "TLS trace: SSL3 alert read:fatal:unsupported certificate"
Hi!
I used "openssl verify" to verify both certificates, using both, -CApath and - CAfile, and both certificates were "OK". I ran those commands as "root", but I also verified that certificate and key can be read as "ldap".
Kind regards, Ulrich Windl
-----Original Message----- From: Philip Guenther pguenther@proofpoint.com Sent: Thursday, March 6, 2025 8:48 AM To: Windl, Ulrich u.windl@ukr.de Cc: noloader@gmail.com; openldap-technical@openldap.org Subject: [EXT] RE: Re: Getting details for "TLS trace: SSL3 alert read:fatal:unsupported certificate"
On Wed, 5 Mar 2025, Windl, Ulrich wrote:
thanks! Actually that's what I did: Comparing the data of the certificate
that
worked with that which does not.
I could not find any relevant difference.
The error being reported is from the OpenSSL library, not from OpenLDAP itself. The certs, or some CA the failing cert would chain through, are different in some way that _is_ relevant.
Philip Guenther
openldap-technical@openldap.org
-
Jeffrey Walton -
Philip Guenther -
Windl, Ulrich