Hello Flo, thanks for your answer, and for the explanation of the certutil output. I have tried your suggestion, first with sudo:
hhuseman@mat-ipa-master-1:~$ sudo kinit -kt /etc/krb5.keytab [sudo] password for hhuseman: Sorry, try again. [sudo] password for hhuseman: Sorry, try again. [sudo] password for hhuseman: sudo: 2 incorrect password attempts I'm quite sure my password is correct, so it seems there's something broken here also, since sudo worked before the certificate update. My next try was running the command as root: hhuseman@mat-ipa-master-1:~$ su - Password: root@mat-ipa-master-1:~$ kinit -kt /etc/krb5.keytab root@mat-ipa-master-1:~$ exit logout As you see, there is no output at all, so I tried it again with -V: root@mat-ipa-master-1:~$ kinit -V -kt /etc/krb5.keytab Using existing cache: persistent:0:krb_ccache_VPUg94b Using principal: host/mat-ipa-master-1.materna-com...@materna-com.de Using keytab: /etc/krb5.keytab Authenticated to Kerberos v5 root@mat-ipa-master-1:~$ I have also re-checked the certificate which is issued by the HTTPS-Server in my browser, it is still the old one. And, I've tried to get the list of certificates with ipa-getcert: root@mat-ipa-master-1:~$ ipa-getcert list Number of certificates and requests being tracked: 5. Request ID '20170303080146': status: CA_UNREACHABLE ca-error: Server at https://mat-ipa-master-1.materna-com.de/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Peer's Certificate has expired.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MATERNA-COM-DE/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MATERNA-COM.DE subject: CN=mat-ipa-master-1.materna-com.de,O=MATERNA-COM.DE expires: 2018-01-13 14:45:00 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv MATERNA-COM-DE track: yes auto-renew: yes Interesting, since the date was still reset to January 11th, so, even the old certificate should be valid: root@mat-ipa-master-1:~$ date Thu Jan 11 05:22:21 CET 2018 Nevertheless, I've set the date to actual time by sync'ing it to our NTP-Server: root@mat-ipa-master-1:~$ ntpdate omcix 24 Jan 19:09:00 ntpdate[32699]: step time server 172.30.96.6 offset 1172766.789568 sec root@mat-ipa-master-1:~$ date Wed Jan 24 19:09:06 CET 2018 But, ipa-getcert list is still falling: root@mat-ipa-master-1:~$ ipa-getcert list Number of certificates and requests being tracked: 5. Request ID '20170303080146': status: NEED_TO_SUBMIT ca-error: Server at https://mat-ipa-master-1.materna-com.de/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Peer's Certificate has expired.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MATERNA-COM-DE/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MATERNA-COM.DE subject: CN=mat-ipa-master-1.materna-com.de,O=MATERNA-COM.DE expires: 2018-01-13 14:45:00 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv MATERNA-COM-DE track: yes auto-renew: yes root@mat-ipa-master-1:~$ To ensure everything's running I've issued an ipactl: root@mat-ipa-master-1:~$ ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING pki-tomcatd Service: STOPPED ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful root@mat-ipa-master-1:~$ So it seems everything's ok except of the PKI, I've tried to restart it, but it fails: root@mat-ipa-master-1:~$ ipactl start pki-tomcatd You must specify one action root@mat-ipa-master-1:~$ ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting pki-tomcatd Service Failed to start pki-tomcatd Service Shutting down Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failed Aborting ipactl root@mat-ipa-master-1:~$ I hope this helps to track down the problem a bit... Many thanks and regards from Germany, Harald -- Dipl.-Ing. (FH) Harald Husemann Senior System Administrator Managed Services Phone: +49 231 9505-222 Mobile: +49 1570 11 22 22 2 harald.husem...@materna.de www.materna.de | Newsletter | Twitter | XING | Facebook | google+ Materna GmbH | Voßkuhle 37 | D-44141 Dortmund | Germany Geschäftsführer: Helmut Binder, Michael Knopp Amtsgericht Dortmund HRB 5839 -----Ursprüngliche Nachricht----- Von: Florence Blanc-Renaud [mailto:f...@redhat.com] Gesendet: Mittwoch, 24. Januar 2018 17:20 An: FreeIPA users list <freeipa-users@lists.fedorahosted.org> Cc: Husemann, Harald <harald.husem...@materna.de> Betreff: Re: [Freeipa-users] Howto renew certificates with external CA? On 01/24/2018 12:35 PM, Harald Husemann via FreeIPA-users wrote: > Hello IPA-experts, > > we are running FreeIPA version 4.4.0 with an external CA (our own one), > everything was working fine until the CA certificate expired which > happened at January 13th. > Since i was on vacation and the basic functions were still available > no-one created a new certificate, so, it's now my task. > As explained in > https://www.freeipa.org/page/Howto/CA_Certificate_Renewal, I've reset > the time to January 10th, created a new certificate which is valid from > 2017 to 2023, and installed it with ipa-cacert-manage. > Afterwards, I did an ipa-certupdate, the server certificates were > updated and the cert8.db in /etc/httpd/alias contains the new valid CA. > But, the expiration date of the certificate itself is still January > 13th, so, the certificate is still expired: > > root@mat-ipa-master-1:~$ /usr/bin/certutil -d /etc/httpd/alias -L -n > "MATERNA-COM.DE IPA CA" > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 36 (0x24) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "E=oc...@materna.de,CN=Materna OC CA,OU=OC RZ,O=Materna > GmbH, > L=Dortmund,ST=NRW,C=DE" > Validity: > Not Before: Mon Jan 23 14:45:00 2017 > Not After : Mon Jan 23 14:45:00 2023 > Subject: "CN=Certificate Authority,O=MATERNA-COM.DE" > (...) > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Valid CA > Trusted CA > Object Signing Flags: > Valid CA > Trusted CA > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 23 (0x17) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "E=oc...@materna.de,CN=Materna OC CA,OU=OC RZ,O=Materna > GmbH, > L=Dortmund,ST=NRW,C=DE" > Validity: > Not Before: Fri Jan 13 14:45:00 2017 > Not After : Sat Jan 13 14:45:00 2018 > Subject: "CN=Certificate Authority,O=MATERNA-COM.DE" > (...) > > root@mat-ipa-master-1:~$ Hi, in the above output we can see 2 different certificates for "CN=Certificate Authority,O=MATERNA-COM.DE", which is an expected behavior: the database still contains the old one (Not After: Sat Jan 13 14:45:00 2018) but also contains the new one (Not After : Mon Jan 23 14:45:00 2023). So from this point of view, IPA CA cert was properly renewed and distributed to the httpd NSS database. > > > I have only checked this one, but I'd suppose the others are also not > updated. AFAIK certmonger is responsible the renewal, so, I've restarted > it and hoped it would grab my certificate and renew it - but it seems > there is a problem, journalctl -u certmonger gives > > Jan 24 11:22:43 mat-ipa-master-1.materna-com.de systemd[1]: Starting > Certificate monitoring and PKI enrollment... > Jan 24 11:22:44 mat-ipa-master-1.materna-com.de systemd[1]: Started > Certificate monitoring and PKI enrollment. > Jan 24 11:22:48 mat-ipa-master-1.materna-com.de certmonger[1026]: > 2018-01-24 11:22:48 [1026] Error setting up ccache for "host" service on > client using default keytab: Cannot contact any KDC for realm > 'MATERNA-COM.DE'. > Jan 24 11:22:48 mat-ipa-master-1.materna-com.de certmonger[1026]: > 2018-01-24 11:22:48 [1026] Error setting up ccache for "host" service on > client using default keytab: Cannot contact any KDC for realm > 'MATERNA-COM.DE'. > Jan 24 11:22:58 mat-ipa-master-1.materna-com.de certmonger[1026]: > 2018-01-24 11:22:58 [1026] Error 7 connecting to > https://mat-ipa-master-1.materna-com.de:8443/ca/agent/ca/profileReview: > Couldn't connect to server. > Jan 24 11:23:00 mat-ipa-master-1.materna-com.de > dogtag-ipa-ca-renew-agent-submit[2282]: Traceback (most recent call last): > File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line > 511, in <module> > sys.exit(main()) > File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line > 490, in main > ipautil.kinit_keytab(principal, paths.KRB5_KEYTAB, ccache_filename) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1314, > in kinit_keytab > cred = gssapi.Credentials(name=name, store=store, usage='initiate') > File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 64, in > __new__ > store=store) > File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 148, in > acquire > usage) > File "ext_cred_store.pyx", line 182, in > gssapi.raw.ext_cred_store.acquire_cred_from > (gssapi/raw/ext_cred_store.c:1732) > GSSError: Major (851968): Unspecified GSS failure. Minor code may > provide more information, Minor (2529639068): Cannot contact any KDC for > realm 'MA > Jan 24 11:23:00 mat-ipa-master-1.materna-com.de certmonger[1026]: > 2018-01-24 11:23:00 [1026] Internal error > The traceback is generated by the helper launched to renew IPA CA. This helper authenticates using /etc/krb5.keytab but according to the traces, was unable to reach the Kerberos server. Can you manually try to perform $ sudo kinit -kt /etc/krb5.keytab and check its output? Flo > Any help is greatly appreciated since I'm stuck here... If it helps, I > have a clean backup of the IPA master which was written yesterday > evening, so, I can use this one to "start over" if I've already mixed up > things. > > Thanks and kind regards from Germany, > > Harald > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org