Summarizing.
If you have the original certs I'd definitely try restoring those.
You'll need to go back in time a few days in order to restart the CA.
Once the CA comes back up I'd suggest using the -N option to be sure the
subject is ok and renew the certs manually one at a time.
IPA loads profiles from LDAP which is why the on-disk doesn't seem to
match up.
rob
Leo Galambos via FreeIPA-users wrote:
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 -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
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/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure