Travis West via FreeIPA-users wrote:
In the apache error log I found this that is generated when, in the
UI, I try to access Authentication > Certificates > Certificate Authorities.
[Wed Apr 03 16:33:28.439180 2024] [:error] [pid 19048] ipa: INFO: [jsonserver_session]
twest(a)IPA.****.NET: cert_find(None, version=u'2.230'): SUCCESS
[Wed Apr 03 16:33:30.661528 2024] [:warn] [pid 19601] [client IP.ADD.RE.SS:61691] failed
to set perms (3140) on file (/var/run/ipa/ccaches/twest(a)IPA.****.NET)!, referer:
https://ipa1-sea2.ipa.****.net/ipa/ui/
[Wed Apr 03 16:33:30.720054 2024] [:error] [pid 19047] ipa: INFO: [jsonserver_session]
twest(a)IPA.****.NET: ca_find(u'', sizelimit=0, version=u'2.230',
pkey_only=True): SUCCESS
[Wed Apr 03 16:33:30.731584 2024] [:warn] [pid 19601] [client IP.ADD.RE.SS:61691] failed
to set perms (3140) on file (/var/run/ipa/ccaches/twest(a)IPA.****.NET)!, referer:
https://ipa1-sea2.ipa.****.net/ipa/ui/
[Wed Apr 03 16:33:30.831428 2024] [:error] [pid 19055] Bad remote server certificate:
-8179
[Wed Apr 03 16:33:30.831479 2024] [:error] [pid 19055] SSL Library Error: -8179
Certificate is signed by an unknown issuer
[Wed Apr 03 16:33:30.831557 2024] [:error] [pid 19055] Re-negotiation handshake failed:
Not accepted by client!?
[Wed Apr 03 16:33:30.831672 2024] [:error] [pid 19055] SSL Library Error: -12116 Unknown
[Wed Apr 03 16:33:30.832809 2024] [:error] [pid 19048] ipa: INFO: twest(a)IPA.****.NET:
batch: ca_show(u'ipa'): NetworkError
[Wed Apr 03 16:33:30.833300 2024] [:error] [pid 19048] ipa: INFO: [jsonserver_session]
twest(a)IPA.****.NET: batch(({u'params': ([u'ipa'], {}), u'method':
u'ca_show'},), version=u'2.230'): SUCCESS
but no indication of which certificate it is complaining about. I thought maybe the IPA
RA cert, but that is definitely signed by this CA and doesn't expires on 2026.
The certs I generated and imported to /etc/pki/pki-tomcat/alias are also signed by the
CA.
Apache, via the IPA API, is acting as the client in this case. So Apache
doesn't trust the CA certificate (unlikely), or the Server-Cert cert-pki-ca.
You can validate it directly with:
# certutil -V -u V -d /etc/pki/pki-tomcat/alias -n 'Server-Cert
cert-pki-ca' -e -f /etc/pki/pki-tomcat/alias/pwdfile.txt
Also, given the subject issues you ran into I guess I'd also verify that
the ASN.1 is correct in the issued certificates. This will be easier
since you have them as PEM files already:
# openssl asn1parse -inform pem -in /path/to/cert.pem
In the output you should see each component of the issuer and subject
broken out like:
...
37:d=5 hl=2 l= 3 prim: OBJECT :organizationName
42:d=5 hl=2 l= 12 prim: UTF8STRING :EXAMPLE.TEST
56:d=3 hl=2 l= 30 cons: SET
58:d=4 hl=2 l= 28 cons: SEQUENCE
60:d=5 hl=2 l= 3 prim: OBJECT :commonName
65:d=5 hl=2 l= 21 prim: UTF8STRING :Certificate Authority
88:d=2 hl=2 l= 30 cons: SEQUENCE
90:d=3 hl=2 l= 13 prim: UTCTIME :240221205457Z
105:d=3 hl=2 l= 13 prim: UTCTIME :260221205457Z
120:d=2 hl=2 l= 50 cons: SEQUENCE
122:d=3 hl=2 l= 21 cons: SET
124:d=4 hl=2 l= 19 cons: SEQUENCE
126:d=5 hl=2 l= 3 prim: OBJECT :organizationName
131:d=5 hl=2 l= 12 prim: UTF8STRING :EXAMPLE.TEST
145:d=3 hl=2 l= 25 cons: SET
147:d=4 hl=2 l= 23 cons: SEQUENCE
149:d=5 hl=2 l= 3 prim: OBJECT :commonName
154:d=5 hl=2 l= 16 prim: UTF8STRING :ipa.example.test
...
And finally, and this might be kinda nutty, but you can use certmonger
to force issue a new certificate using the resubmit command. I'd
snapshot things but that could be a way to get freshly issued certs that
might play more nicely with others.
rob