On Thu, May 02, 2013 at 10:59:11AM -0500, Toasted Penguin wrote:
> Running FreeIPA 2.1.4 and ran into an issue where a Server-Cert did not
> auto-renew.
>
> ipa-getcert list
> Number of certificates and requests being tracked: 4.
[snip]
> Request ID '20120615190133':
> status: CA_UNCONFIGURED
> ca-error: Error setting up ccache for local "host" service using default
> keytab.
> stuck: yes
> key pair storage:
> type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
> Certificate DB'
> certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
> CA: IPA
> issuer:
> subject:
> expires: unknown
> track: yes
> auto-renew: yes
That error's not expected. Assuming there aren't any permissions-
related problems (due to SELinux policy or regular filesystem
permissions) preventing the submission helper from reading the keytab,
can you verify that "hostname" prints "ipa01.ctidata.net", and that
"kinit -k host/ipa01.ctidata.net" succeeds?
> Request ID '20120925200227':
> status: GENERATING_CSR
> 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=CTIDATA.NET
> subject: CN=ipa01.ctidata.net,O=CTIDATA.NET
> expires: 2013-03-24 19:56:36 UTC
> eku: id-kp-serverAuth
> track: yes
> auto-renew: yes
>
> I verified that the IPA keytab is populated:
>
> klist -kt /etc/krb5.keytab
> Keytab name: WRFILE:/etc/krb5.keytab
> KVNO Timestamp Principal
> ---- -----------------
> --------------------------------------------------------
> 2 07/06/11 21:51:43 host/ipa01.ctidata....@ctidata.net
> 2 07/06/11 21:51:43 host/ipa01.ctidata....@ctidata.net
> 2 07/06/11 21:51:43 host/ipa01.ctidata....@ctidata.net
> 2 07/06/11 21:51:43 host/ipa01.ctidata....@ctidata.net
> 2 07/06/11 21:51:43 host/ipa01.ctidata....@ctidata.net
> 2 07/06/11 21:51:43 host/ipa01.ctidata....@ctidata.net
> 4 07/18/12 21:20:41 host/ipa01.ctidata....@ctidata.net
> 4 07/18/12 21:20:41 host/ipa01.ctidata....@ctidata.net
> 4 07/18/12 21:20:41 host/ipa01.ctidata....@ctidata.net
> 4 07/18/12 21:20:41 host/ipa01.ctidata....@ctidata.net
> 5 07/18/12 21:21:00 host/ipa01.ctidata....@ctidata.net
> 5 07/18/12 21:21:00 host/ipa01.ctidata....@ctidata.net
> 5 07/18/12 21:21:00 host/ipa01.ctidata....@ctidata.net
> 5 07/18/12 21:21:00 host/ipa01.ctidata....@ctidata.net
> 6 05/02/13 15:02:10 host/ipa01.ctidata....@ctidata.net
> 6 05/02/13 15:02:10 host/ipa01.ctidata....@ctidata.net
> 6 05/02/13 15:02:10 host/ipa01.ctidata....@ctidata.net
> 6 05/02/13 15:02:10 host/ipa01.ctidata....@ctidata.net
>
> and ran kvno host/ipa01.ctidata.net to see what the KDC shows for this
> principle:
> host/ipa01.ctidata....@ctidata.net: kvno = 6
>
> Not sure what caused the ca_errors but I need to at least manually renew
> the certs and then figure out what went wrong.
>
> Any advice on what the ca_errors mean and how I can fix the issue?
The "Unable to determine principal name for signing request." stems from
IPA's certificate submission API's requirement that each certificate
request include the associated Kerberos principal name, and certmonger
not knowing what value to send.
I'm guessing that there wasn't one specified with the -K option when
certmonger was told to keep an eye on the certificate, and if there was
already a certificate there, a principla name couldn't be read from it.
Based on where the certificate's being stored, it's probably intended to
be used for the "HTTP" service on the host, so its principal name would
be "HTTP/ipa01.ctidata....@ctidata.net". If you run:
ipa-getcert resubmit -i 20120925200227 \
-K HTTP/ipa01.ctidata....@ctidata.net
that should provide certmonger with the missing information and get
things going again.
HTH,
Nalin
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
