On ti, 20 elo 2019, Thomas Kropeit via FreeIPA-users wrote:
On 19.08.2019 13:41, Alexander Bokovoy wrote:
> On ma, 19 elo 2019, Thomas Kropeit via FreeIPA-users wrote:
>> Over the weekend, my original "NSS Certificate DB" certificate
>> expired. It was automatically renewed, however in a new location:
>>
>> # ipa-getcert list
>> Number of certificates and requests being tracked: 10.
>> Request ID '20180929060059':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>>
type=NSSDB,location='/etc/dirsrv/slapd-IPA-PHYSEC-DE',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-PHYSEC-DE
>> certificate:
>>
type=NSSDB,location='/etc/dirsrv/slapd-IPA-PHYSEC-DE',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=IPA.PHYSEC.DE
>> subject: CN=master.ipa.physec.de,O=IPA.PHYSEC.DE
>> expires: 2021-07-20 14:25:43 UTC
>> principal name: ldap/master.ipa.physec.de(a)IPA.PHYSEC.DE
>> 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
>> IPA-PHYSEC-DE
>> track: yes
>> auto-renew: yes
>> Request ID '20180929060107':
>> status: MONITORING
>> ca-error: Unable to determine principal name for signing request.
>> stuck: no
>> key pair storage:
>>
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> certificate:
>>
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=IPA.PHYSEC.DE
>> subject: CN=master.ipa.physec.de,O=IPA.PHYSEC.DE
>> expires: 2019-08-17 12:45:50 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_httpd
>> track: yes
>> auto-renew: yes
>>
>> I managed to restart the FreeIPA service by adding
>> `NSSEnforceValidCerts off` to `/etc/httpd/conf.d/nss.conf`. But
>> logging into the webinterface still yields the following error in httpd:
>> [Mon Aug 19 10:36:05.722736 2019] [:error] [pid 12798] ipa: INFO: 401
>> Unauthorized: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
>> failed (_ssl.c:618)
>> [Mon Aug 19 10:36:05.723894 2019] [:error] [pid 12802] SSL Library
>> Error: -12269 The server has rejected your certificate as expired
>>
>> I have intentionally not copied the new certificate to
>> `/etc/httpd/alias` as I am not aware of all the involved components
>> and fear that this might break something.
>>
>> My system is running a fully patched CentOS 7.6, running FreeIPA
>> 4.6.4-10.el7.centos.6.
>>
>> What should I do to resolve this issue, simply replacing the
>> certificates, or is there a better method?
> These two certificates are different as they issued to different
> Kerberos principals (ldap/... and HTTP/...). In the other case you just
> need to add
>
> ipa-getcert resubmit -i 20180929060107 -K HTTP/master.ipa.physec.de
>
> as this is what your ca-error says:
>
>> ca-error: Unable to determine principal name for signing request.
>
> But to submit it you'd need to get back in time when HTTP cert is valid
> yet (before 2019-08-17) and not too far to have LDAP certificate invalid
> yet (after 2019-07-20).
>
Thanks, this works great!
Now that I can access the webui again, I see that many certificates were
automatically renewed. This is the behavior I expected.
Is the HTTP cert an exception to this, will I have to manually renew it
again in ~2 years? If so, are there other certificates (of the FreeIPA
core, not clients) which are not automatically renewed?
It should have been renewed as well. However, something caused the
certificate request to drop Kerberos principal from it -- we don't do
anything with the request after we issue them, so this must have been
something local to your operations. As the Kerberos principal was
missing in the certificate request and is mandatory to present for the
certificate template used by that certificate, it was held off.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland