Hiya.
Yes, i did not replace the LDAP certificate, so that is why the currently used certificate (shown below) is the certificate created by dogtag/FreeIPA. Correct?
$ certutil -d /etc/dirsrv/slapd-INSTANCE/ -L -n Server-Cert Certificate: Data: Version: 3 (0x2) Serial Number: 77 (0x4d) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=INTRA.UIBK.AC.AT" Validity: Not Before: Tue Nov 10 14:28:07 2020 Not After : Fri Nov 11 14:28:07 2022 Subject: "CN=ipa1.intra.uibk.ac.at,O=INTRA.UIBK.AC.AT" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: c1:c5:c8:f4:98:2b:26:97:c4:11:6f:f2:59:67:03:f4: e9:fc:6b:16:50:3a:eb:02:02:56:e4:f5:75:48:3c:37: 8d:76:37:3c:b9:ef:3a:17:0d:9e:d7:b7:48:b7:00:91: 7c:fe:bd:57:4c:d4:4e:a0:b7:6f:21:80:29:bf:0a:8c: c5:fd:a7:3f:e5:1f:00:f8:98:68:92:1c:b4:fd:2d:14: ac:66:7e:cd:ac:00:ac:8b:d7:bf:37:c7:89:f6:da:ae: 57:c7:d3:7a:74:3b:a8:58:cc:41:56:d6:3e:3d:75:12: 96:65:a2:0d:6f:a3:f5:52:8a:44:c8:e5:68:58:73:c7: 45:df:a1:2a:c3:83:3e:44:24:4f:dc:4c:9a:5f:91:2e: d5:5b:f1:39:e2:91:e5:dd:0d:23:eb:44:bd:ca:fe:d7: 7f:d0:50:1b:57:10:f1:84:ad:c6:55:47:38:a9:e4:09: d1:b1:71:99:bf:b2:17:4f:b4:7b:25:fc:63:1d:40:f2: 46:72:33:22:d8:3a:4e:da:2b:64:21:60:32:f9:b2:23: 65:a7:5e:1a:92:7f:dc:9a:0e:97:99:fa:76:6a:80:8f: 9e:15:d9:a8:db:ea:67:32:7e:9f:c3:25:91:5f:ea:8e: c4:1e:5f:97:43:ad:61:15:23:67:9f:1f:49:c3:b9:77 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: e5:de:f4:d6:7d:aa:11:1d:5b:a6:50:0d:17:6c:76:ea: dc:5f:2a:a6
Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://ipa-ca.intra.uibk.ac.at/ca/ocsp"
Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment
Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate
Name: CRL Distribution Points Distribution point: URI: "http://ipa-ca.intra.uibk.ac.at/ipa/crl/MasterCRL.bin" CRL issuer: Directory Name: "CN=Certificate Authority,O=ipaca"
Name: Certificate Subject Key ID Data: 5b:62:26:c4:50:f5:63:50:4a:1b:80:7b:88:c1:a3:f9: f1:3d:11:7c
Name: Certificate Subject Alt Name Other Name: "ldap/ipa1.intra.uibk.ac.at@INTRA.UIBK.AC.AT" OID: Microsoft NT Principal Name Other Name: Sequence { [0]: { 1b:10:49:4e:54:52:41:2e:55:49:42:4b:2e:41:43:2e: 41:54 } [1]: { Sequence { [0]: { 1 (0x1) } [1]: { Sequence { 1b:04:6c:64:61:70
1b:15:69:70:61:31:2e:69:6e:74:72:61:2e:75:69: 62:6b:2e:61:63:2e:61:74 } } } } } OID: OID.1.3.6.1.5.2.2
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 79:3f:6b:93:20:bf:ba:1f:d6:ce:0b:23:74:77:3e:33: ad:08:fa:7c:c3:ad:f1:64:d4:40:be:62:6d:6a:5d:db: 40:5f:00:5b:76:34:0b:37:ee:71:fc:c4:0e:77:be:70: 3e:89:11:46:45:78:b9:9c:ab:36:42:19:0c:8e:38:8a: 9f:2b:8e:ef:25:ee:cb:d1:93:10:c0:93:22:fd:9b:22: fb:78:c7:52:ee:65:15:9f:80:d3:49:85:74:e1:56:09: 30:da:48:f2:aa:36:83:d8:cc:d0:d8:f3:ab:33:1d:0a: 52:97:e7:28:79:d0:d8:93:9a:43:42:cf:b8:00:7d:f8: 55:55:fb:b3:60:37:9d:0e:d0:f7:f8:da:d0:ef:c2:39: 24:f3:a8:87:e0:3d:ad:82:d8:87:72:c5:8a:7c:aa:16: 10:2f:18:8d:ff:52:ef:fa:60:1c:56:9f:1d:1a:97:19: 60:7f:fb:5a:f0:d7:b5:1a:bd:51:7c:86:7d:d4:33:d0: 69:64:31:1f:32:f2:c7:35:18:22:9f:31:52:63:fa:94: 83:c6:48:8c:20:38:f9:3b:bd:ec:2d:8e:b1:eb:4b:1c: 0c:b0:43:cb:3d:2d:1d:43:31:7e:e4:8c:ca:f9:c7:c2: bf:d7:39:7d:a9:ec:f7:ee:8c:34:7f:af:02:56:9f:fa Fingerprint (SHA-256):
24:6E:20:24:A8:68:58:C0:40:E4:F1:76:FF:AC:1B:B9:A2:BA:2C:01:BA:33:15:91:D8:2E:99:3E:64:34:C8:49 Fingerprint (SHA1): EA:30:D8:FC:7C:61:86:0A:3A:83:6B:74:56:48:87:44:91:1C:32:0A
Mozilla-CA-Policy: false (attribute missing) Certificate Trust Flags: SSL Flags: User Email Flags: User Object Signing Flags: User
Am 21.06.22 um 19:01 schrieb Alexander Bokovoy:
On ti, 21 kesä 2022, Alex Bihlmaier via FreeIPA-users wrote:
Hiya.
I am running IPA server 4.6.8-5 on CentOS 7 and there is an issue registering a CentOS 8 client to this IPA System.
When using CentOS 7 registering works flawless.
On CentOS 8 it fails because: " Unable to initialize STARTTLS session Connect error: TLS: hostname does not match subjectAltName in peer certificate Failed to bind to server! Retrying with pre-4.0 keytab retrieval method... Unable to initialize STARTTLS session Connect error: TLS: hostname does not match subjectAltName in peer certificate Failed to bind to server! Failed to get keytab "
I will attach the complete log.
You have replaced HTTP certificate but probably did not replace LDAP one, is that correct?
Can you show what certificate is used by the LDAP server?
certutil -d /etc/dirsrv/slapd-INSTANCE/ -L -n Server-Cert
where INSTANCE is your instance value, e.g. for example.com that would be EXAMPLE-COM