On 2/15/22 21:25, Rob Crittenden wrote:
Leo Galambos via FreeIPA-users wrote:
Hello,
our FreeIPA was running with correct certificates for 2 years (subject
"CN=ipa.hq.company,O=HQ.COMPANY"). Unfortunately, the new certificates
(ocspSigningCert, auditSigningCert) were recreated with simple
"CN=localhost" (automatically), i.e. the original value
"CN=ipa.hq.company,O=HQ.COMPANY" was ignored by certmonger.
Is this the renewal master? (ipa config-show | grep renewal)
Yes, it is: IPA CA renewal master: ipa.hq.company
You stripped out the key and certificate storage lines, can we see that
as well?
Everything is default, dir /etc/pki/pki-tomcat/alias and pin are set, e.g.:
Request ID '20210120221129':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=HQ.COMPANY
subject: CN=localhost
expires: 2024-02-04 22:28:36 CET
eku: id-kp-OCSPSigning
profile: caOCSPCert
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
^^^ this one is missing in the NSS DB now (the rotation removed it from
NSS DB!), but 'auditSigningCert' seems to be fine (except of its
CN=localhost). PIN is identical to /etc/pki/pki-tomcat/alias/pwdfile.txt
*** Before rotation:
# certutil -L -d alias
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
Server-Cert cert-pki-ca u,u,u
*** After rotation:
# certutil -L -d /etc/pki/pki-tomcat/alias
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu
subsystemCert cert-pki-ca u,u,u
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
# certutil -L -d /etc/pki/pki-tomcat/alias -n 'ocspSigningCert cert-pki-ca'
certutil: Could not find cert: ocspSigningCert cert-pki-ca
: PR_FILE_NOT_FOUND_ERROR: File not found
# certutil -L -d /etc/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-ca'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 31 (0x1f)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=HQ.COMPANY"
Validity:
Not Before: Mon Feb 14 21:29:37 2022
Not After : Sun Feb 04 21:29:37 2024
Subject: "CN=localhost"
Anyway, if I import my previous 'ocspSigningCert cert-pki-ca' back into
/etc/pki/pki-tomcat/alias and rollback ca.ocsp_signing.cert and
ca.ocsp_signing.certreq in CS.cfg - would it be enough to fix this?
The cow may be out of the barn already, but certmonger should have
already been aware of the hostname when the cert was re-issued. You can
determine the request file name in /var/lib/certmonger/requests by
greeping for the request ID (it may or may not match the filename).
All parameters seems to be OK in the request files, except of the
CN=localhost related to two "new" buggy certificates.
Then grep template_ from that file. At this point it may be CN=localhost
but it would be interesting to see what is there.
BTW templates: auditSigningCert points to caSignedLogCert,
ocspSigningCert points to caOCSPCert. Both caSignedLogCert.cfg and
caOCSPCert.cfg exist in /var/lib/pki/pki-tomcat/ca/profiles/ca. None of
them is owned by RPM package (O/S is RHEL 8.5). caOCSPCert.profile also
exists in /var/lib/pki/pki-tomcat/conf/ca, again not owned by any RPM.
caSignedLogCert.profile does not exist on my disk AFAIK.
ad ocspSigningCert) There is a correct value template_subject=CN=OCSP
Subsystem,O=HQ.COMPANY
'csr' attribute in the request file includes CSR with:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN = localhost
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
'cert' attribute has the respective cert.
After `getcert resubmit ...` it cannot be changed due to "status:
CA_UNREACHABLE".
ad auditSigningCert) template_subject=CN=CA Audit,O=HQ.COMPANY
After `getcert resubmit ...` the 'csr' attribute seems to be OK:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: O = HQ.COMPANY, CN = CA Audit
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
'cert' attribute is still the old one (with CN=localhost) due to "Error
7 connecting to http://ipa.hq.company:8080/ca/ee/ca/profileSubmit:
Couldn't connect to server" (tomcat is down - OCSP cert is missing).
CS.cfg: ca.audit_signing.cert identical to 'auditSigningCert
cert-pki-ca' (NSS DB /etc/pki/pki-tomcat/alias), ca.signing.cert is
'caSigningCert cert-pki-ca', ca.sslserver.cert is 'Server-Cert
cert-pki-ca', ca.subsystem.cert is 'subsystemCert cert-pki-ca', and
ca.ocsp_signing.cert is identical to 'cert' attribute of the
certmonger's ocspSigningCert request file.
# ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso
returns "userCertificate" identical to CS.cfg's ca.subsystem.cert. So
this part of the system seems to be OK.
Summary: ocspSigningCert was rotated in CS.cfg, then it was lost, and
the old one was removed from NSS DB.
During rotation, I can see this sequence in Tomcat's CA debug log:
1) 'Server-Cert cert-pki-ca' was processed with "INFO: EnrollProfile: -
subject: CN=ipa.hq.company,O=HQ.COMPANY"
2) 'ocspSigningCert cert-pki-ca' came with "INFO: EnrollProfile: -
subject: CN=localhost"
3) after less than 1 minute, something fails: [AuthorityMonitor]
WARNING: CAEngine: Error initializing lightweight CA: Failed to update
certificate; nickname conflict
Failed to update certificate; nickname conflict
at
com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:426)
at
org.dogtagpki.server.ca.CAEngine.readAuthority(CAEngine.java:1441)
at com.netscape.ca.AuthorityMonitor.run(AuthorityMonitor.java:162)
at java.lang.Thread.run(Thread.java:750)
Caused by: Failed to update certificate; nickname conflict
at
com.netscape.ca.CertificateAuthority.checkForNewerCert(CertificateAuthority.java:504)
at
com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:418)
... 3 more
Caused by: org.mozilla.jss.NicknameConflictException
at org.mozilla.jss.CryptoManager.importCertPackageNative(Native
Method)
at
org.mozilla.jss.CryptoManager.importUserCACertPackage(CryptoManager.java:739)
at
com.netscape.ca.CertificateAuthority.checkForNewerCert(CertificateAuthority.java:480)
... 4 more
Cheers,
LG
It should be straightforward to get new certificates by using the -N
<subject> option with resubmit but it would be nice to try to figure out
how it got into this situation.
For example:
# getcert resubmit -i 20210120221129 -N 'CN=OCSP Subsystem,O=HQ.COMPANY'
-v -w
Just for record:
Unfortunately, OCSP cannot be recovered this way (NSS DB does not
include OCSP cert/key pair). I tried to recover auditSigningCert, but it
also fails due to dead tomcat:
# getcert resubmit -i 20210120221127 -N 'CN=CA Audit,O=HQ.COMPANY' -v -w
Resubmitting "20210120221127" to "dogtag-ipa-ca-renew-agent".
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State CA_UNREACHABLE, stuck: no.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
