[Freeipa-users] Apparently transient error cl5DBData2Entry - Invalid data version
Hi We have 3 IPA servers which we are in the process of updating from RHEL 7.7 to RHEL 7.8. Servers X, Z are at: ipa-server-4.6.6-11.el7.x86_64 (RHEL 7.8) Server W is at: ipa-server-4.6.5-11.el7_7.3.x86_64 (RHEL 7.7) Server X was updated some time ago, and server Z was updated last Thursday. I was doing some checks of the log files before our planned update of server W to RHEL 7.8 tomorrow and found the following in /var/log/dirsrv/slapd-REALM/errors: [26/Apr/2020:22:00:21.704887592 +0100] - INFO - dblayer_copy_directory - Backing up file 119 (/var/lib/dirsrv/slapd-REALM/bak/REALM/ipaca/vlv#cacompleterenewalpkitomcatindex.db) [26/Apr/2020:22:00:23.627421118 +0100] - ERR - NSMMReplicationPlugin - changelog program - cl5DBData2Entry - Invalid data version [26/Apr/2020:22:00:24.760704543 +0100] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-REALM/db/ipaca/vlv#cacompleterenewalpkitomcatindex.db to /var/lib/dirsrv/slapd-REALM/bak/REALM/ipaca/vlv#cacompleterenewalpkitomcatindex.db [26/Apr/2020:22:00:24.776815976 +0100] - ERR - NSMMReplicationPlugin - changelog program - cl5DBData2Entry - Invalid data version The errors were generated during our cronjob that runs this each night: /sbin/ipa-backup --data --online The errors don't seem to have been present the last two nights. Would I be right to assume that this is just some transient inconsistency caused by doing the online backup or should I be more worried even though the error hasn't occurred since? Thanks for any insights on this. Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] Re: Replica not renewing IPA certificates
On 31/01/2020 13:25, Florence Blanc-Renaud wrote: On 1/31/20 2:03 PM, Roderick Johnstone via FreeIPA-users wrote: Hi This is freeipa (ipa-server-4.6.5-11.el7_7.3.x86_64) on RHEL7 with freeipa's own internal CA. One of my ipa server replicas (host3) has not renewed its IPA system certificates and is now showing ca-error: Invalid cookie: u'' in the 'getcert list' output for certificates: "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca", "subsystemCert cert-pki-ca", and the certificate in the file /var/lib/ipa/ra-agent.pem As far as I can see, the sequence of events has been as follows: host3 noticed the certificates needed renewing at 30 Jan 2020 05:37 and certmonger initiated a renewal. The state of those certificates went from MONITORING to CA_WORKING but the certificates were not renewed. The CA renewal master (host1) noticed its same set of certificates (plus "Server-Cert cert-pki-ca") needed renewing at 30 Jan 2020 07:28 and renewed them successfully. Another replica (host2) noticed that its certificates needed renewing at 30 Jan 2020 07:32 and renewed them successfully. At 30 Jan 13:37 on host3 the certificates needing to be renewed went from CA_WORKING back to MONITORING, but 'getcert list' now shows them with: ca-error: Invalid cookie: u'' and they still haven't renewed. Hi the 'Invalid cookie' error message is an issue already tracked in ticket 8164 Renewed certs are not picked up by IPA CAs [1]. When a replica tries to renew a cert before the renewal master, the output of getcert list should be 'CA-WORKING' and certmonger should retry 8 hours laters (see the code in [2]). Since you are hitting the issue 8164, you can manually force the renewal on the replica (once the CA renewal master has actually renewed the cert) with getcert resubmit. HTH, flo Hi Flo Thank you very much! The getcert resubmit has successfully renewed all the certificates in need of renewal. The comments from Rob on the commit to fix this issue are very helpful in understanding what is happening too. Roderick [1] https://pagure.io/freeipa/issue/8164 [2] https://pagure.io/freeipa/blob/b5b9efeb57c010443c33c6f14f831abdbd804e78/f/install/certmonger/dogtag-ipa-ca-renew-agent-submit.in#_370 I haven't seen certmonger attempt to try the renewal again on host3 (nothing from certmonger in /var/log/messages since 30 Jan 13:37). While I could try a getcert resubmit on host3 to force it to try again, I'd like to know if what I am seeing is the expected behaviour when a replica tried to renew certificates before the renewal master. How long should I have to wait till certmonger on host3 tries again? - I couldn't find any reference to how often certmonger tries the renewal. Rob Crittenden's freeipa-healthcheck script is now showing the following for host3: ERROR: ipahealthcheck.ipa.certs.IPARAAgent: RA agent description does not match 2;16;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM in LDAP and 2;7;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM expected ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040924: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040920: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040921: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040922: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040923: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040925: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040927: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040926: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180831064406: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConnectivityCheck: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) Each of host1, host2 and host3 are showing serial number 16 in ldap using: ldapsearch -D "cn=directo
[Freeipa-users] Replica not renewing IPA certificates
Hi This is freeipa (ipa-server-4.6.5-11.el7_7.3.x86_64) on RHEL7 with freeipa's own internal CA. One of my ipa server replicas (host3) has not renewed its IPA system certificates and is now showing ca-error: Invalid cookie: u'' in the 'getcert list' output for certificates: "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca", "subsystemCert cert-pki-ca", and the certificate in the file /var/lib/ipa/ra-agent.pem As far as I can see, the sequence of events has been as follows: host3 noticed the certificates needed renewing at 30 Jan 2020 05:37 and certmonger initiated a renewal. The state of those certificates went from MONITORING to CA_WORKING but the certificates were not renewed. The CA renewal master (host1) noticed its same set of certificates (plus "Server-Cert cert-pki-ca") needed renewing at 30 Jan 2020 07:28 and renewed them successfully. Another replica (host2) noticed that its certificates needed renewing at 30 Jan 2020 07:32 and renewed them successfully. At 30 Jan 13:37 on host3 the certificates needing to be renewed went from CA_WORKING back to MONITORING, but 'getcert list' now shows them with: ca-error: Invalid cookie: u'' and they still haven't renewed. I haven't seen certmonger attempt to try the renewal again on host3 (nothing from certmonger in /var/log/messages since 30 Jan 13:37). While I could try a getcert resubmit on host3 to force it to try again, I'd like to know if what I am seeing is the expected behaviour when a replica tried to renew certificates before the renewal master. How long should I have to wait till certmonger on host3 tries again? - I couldn't find any reference to how often certmonger tries the renewal. Rob Crittenden's freeipa-healthcheck script is now showing the following for host3: ERROR: ipahealthcheck.ipa.certs.IPARAAgent: RA agent description does not match 2;16;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM in LDAP and 2;7;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM expected ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040924: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040920: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040921: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040922: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040923: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040925: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040927: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040926: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180831064406: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConnectivityCheck: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) Each of host1, host2 and host3 are showing serial number 16 in ldap using: ldapsearch -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca description At this stage I'm not sure whether this will resolve itself when certmonger tries to renew certificates again or whether I need to be more proactive. I'm happy to supply more logs as necessary. Thanks Roderick ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
[Freeipa-users] LDAP schema query
Hi I've integrated our netapp VSMs (Data onTap 9.4) into our freeipa environment using a simple bind to the ldap servers. freeipa has compat mode enbled. The netapps are currently configured to use the RFC2307 ldap schema and that seems to work well. Now I'm wondering whether using the RFC2307bis schema on the netapps would enable us to not need the compat mode on the ipa servers any more. But, after enabling RFC2307bis there are settings to be made for: RFC 2307bis groupOfUniqueNames Object Class: groupOfUniqueNames RFC 2307bis uniqueMember Attribute: uniqueMember Having read a bit around the ipa schema and checked out whats actually in our ldap server I think these should be set to "groupofnames" and "member" respectively. Can anyone confirm if this is correct please or am I mistaken. Thanks. Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Inconsistencies in account preserved status
On 22/10/2018 21:27, Florence Blanc-Renaud wrote: On 10/22/18 2:10 PM, Roderick Johnstone via FreeIPA-users wrote: Hi This is ipa-server-4.5.4-10.el7_5.4.4.x86_64 on RHEL7.5. I've got four preserved accounts (out of a few hundred preserved accounts). On two of the servers they are showing up correctly as preserved with this command: ipa user-show . On the third server the same command shows the users with the preserved attribute set to false. Based on a few tests changing (other) accounts it seems that replication is generally working fine between all the servers. But: 1) The ipa_check_consistency script is showing all three servers with the same (correct) number of preserved and active users and is showing a good replication status for all server replication agreements. So its not showing fewer preserved accounts on one server correctly. 2) I'm not seeing any replication conflicts on any of the servers through commands like this: # ldapsearch -x -D "cn=directory manager" -W -b "dc=example,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict Hi, which version of 389-ds is installed? In recent versions (>= 1.3.7.4, please see ticket 49043 [1]), you need to use the following search to retrieve the conflict entries: ldapsearch -x -D "cn=Directory Manager" -W -b "dc=example,dc=com" "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict (without objectclass=ldapsubentry, the search won't return any result). flo [1] https://pagure.io/389-ds-base/issue/49043 Hi Flo Thanks for the info here. We are on: 389-ds-base-1.3.7.5-28.el7_5.x86_64 so indeed need the new command to see replication conflicts. But, even with that I'm not seeing any conflicts. I've run it on each server (with my real domain) and still just get: [root@calxw ~]# ldapsearch -x -D "cn=Directory Manager" -W -b "dc=example,dc=com" "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*)) # requesting: * nsds5ReplConflict # # search result search: 2 result: 0 Success # numResponses: 1 So, I'm still confused as to why one of my servers is out of sync with the other two and yet there are apparently no replication conflicts showing. Would still appreciate advice on the best way to resolve this when its more obvious whats going on. Thanks again. Roderick Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # search result search: 2 result: 0 Success # numResponses: 1 3) The dirsrv error log on server with the users not showing as preserved is showing the following entries from last May: [11/May/2018:10:09:31.330807982 +0100] - ERR - managed-entries-plugin - mep_mod_post_op - Unable to find config for origin entry "uid=,cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com". [11/May/2018:10:09:36.294657019 +0100] - ERR - NSMMReplicationPlugin - write_changelog_and_ruv - Can't add a change for uid=,cn=users,cn=accounts,dc=example,dc=com (uniqid: f132de25-54fa11e8-b4d6ec15-cd33af38, optype: 64) to changelog csn 5af55dc900060004 I'd appreciate any thoughts as to why there might be an inconsistency between servers despite there apparently being no replication conflicts and no indication in the ipa_check_consistency script output. What might be the best way to resolve this inconsistency between servers? Thanks Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Inconsistencies in account preserved status
Hi This is ipa-server-4.5.4-10.el7_5.4.4.x86_64 on RHEL7.5. I've got four preserved accounts (out of a few hundred preserved accounts). On two of the servers they are showing up correctly as preserved with this command: ipa user-show . On the third server the same command shows the users with the preserved attribute set to false. Based on a few tests changing (other) accounts it seems that replication is generally working fine between all the servers. But: 1) The ipa_check_consistency script is showing all three servers with the same (correct) number of preserved and active users and is showing a good replication status for all server replication agreements. So its not showing fewer preserved accounts on one server correctly. 2) I'm not seeing any replication conflicts on any of the servers through commands like this: # ldapsearch -x -D "cn=directory manager" -W -b "dc=example,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # search result search: 2 result: 0 Success # numResponses: 1 3) The dirsrv error log on server with the users not showing as preserved is showing the following entries from last May: [11/May/2018:10:09:31.330807982 +0100] - ERR - managed-entries-plugin - mep_mod_post_op - Unable to find config for origin entry "uid=,cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com". [11/May/2018:10:09:36.294657019 +0100] - ERR - NSMMReplicationPlugin - write_changelog_and_ruv - Can't add a change for uid=,cn=users,cn=accounts,dc=example,dc=com (uniqid: f132de25-54fa11e8-b4d6ec15-cd33af38, optype: 64) to changelog csn 5af55dc900060004 I'd appreciate any thoughts as to why there might be an inconsistency between servers despite there apparently being no replication conflicts and no indication in the ipa_check_consistency script output. What might be the best way to resolve this inconsistency between servers? Thanks Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Seeking advice on testing ipa internal certificate renewal
Hi In our current ipa implementation some of the ipa internal certificates are not able to be renewed correctly. After a lot of support both from Redhat and also through this list, neither of which was able to fix the issue, I was advised by Redhat to implement a new instance of ipa and migrate to it. I now have the new ipa instance running on RHEL7 servers, but before migrating clients and users to it would like to test that the ipa certificate renewal will work correctly. However, I don't want to break the new instance! I've read chapters 24 and 26 of the Linux Domain Identity, Authentication and Policy guide and I'm not sure either are relevant to renewing eg 'ocspSigningCert cert-pki-ca', which was one of the ones I was having problems with before. In trying to fix the current ipa implementation we have been using eg 'getcert resubmit -i ' where is the id of the 'ocspSigningCert cert-pki-ca' certificate as shown by 'getcert list'. Is 'getcert resubmit -i ' a sensible way to test renewing a certificate manually in a working ipa instance? Do I need to do anything else to propagate the new certificate to the replica? Do I need to explicitly revoke the old certificate, if so how? Thanks. Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: What does migration mode actually do?
On 09/03/2018 09:13, Florence Blanc-Renaud wrote: On 03/09/2018 09:41 AM, Roderick Johnstone via FreeIPA-users wrote: Hi I'm using migration mode (ipa config-mod --enable-migration=true) to help migrate from one freeipa instance to another. I wasn't able to find any docs on what enabling migration mode actually does, exactly. Can anyone supply details please? Thanks. Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Hi, the migration mode allows to add an entry with a pre-hashed password. When this mode is disabled, this operation would be refused because IPA needs a clear-text password in order to run password policy checks and generate kerberos keys. HTH, Flo Hi Flo So, why wouldn't you want to have that enabled all the time. ie are there any other consequences of having this enabled. Thanks. Roderick ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] What does migration mode actually do?
Hi I'm using migration mode (ipa config-mod --enable-migration=true) to help migrate from one freeipa instance to another. I wasn't able to find any docs on what enabling migration mode actually does, exactly. Can anyone supply details please? Thanks. Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 05/02/2018 19:44, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone wrote: On 31/01/2018 20:36, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 25/01/2018 16:56, Roderick Johnstone via FreeIPA-users wrote: On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 31/01/2018 20:36, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 25/01/2018 16:56, Roderick Johnstone via FreeIPA-users wrote: On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 25/01/2018 16:56, Roderick Johnstone via FreeIPA-users wrote: On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert cert-pki-ca",
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [583] Loc
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [583] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [48576] Adding hook "/usr/lib
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [583] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [48576] Adding hook "/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"" (0). 2017-10-23 00:10:43 [
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [583] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [48576] Adding hook "/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"" (0). 2017-10-23 00:10:43 [942] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in
[Freeipa-users] Re: Certificates renewing with the wrong Subject
On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: Roderick Johnstone via FreeIPA-users wrote: Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what the subject is. I'm not seeing any obvious CSR fields in the /etc/pki/pki-tomcat/ca/CS.cfg file. foo.bar.certreq= The CSR in the certmonger requests file for the auditSigningCert seems to be showing with the correct Subject. This is different from the bad subject showing in the requests file field: cert_subject= The value of cert_subject comes from the issued certificate. and the Subject which is showing in the 'getcert list' output (which is the same as that in the cert_subject= field.> I'm not quite sure what this all means. It is displayed from the data within the tracked certmonger request. certmonger logs to syslog so you can check there or you can stop the process and run it manually with: certmonger -n -d 9 2>&1 | tee certmonger.log That will provide a lot of debugging output that may show what is going on. I've restored certificate databases from backup and put the clock back to a time when certificates are valid and renewed the ocspSigining certificate with: getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302 (I've previously tried without the -N with similar results) What I am seeing in the certmonger logs is: 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401. 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'. 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert cert-pki-ca' to public key. 2017-10-23 00:05:39 [581] Found a certificate with the same nickname but different subject, removing certificate "ocspSigningCert cert-pki-ca" with subject "CN=OCSP Subsystem,O=". 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [583] Located the certificate "ocspSigningCert cert-pki-ca". 2017-10-23 00:05:39 [48576] Adding hook "/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"" (0). 2017-10-23 00:10:43 [942] 0x1d Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" issued by CA and saved. I now ha
[Freeipa-users] Certificates renewing with the wrong Subject
Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/ until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. Thanks Roderick Johnstone ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
