On Mon, May 11, 2015 at 05:14:16PM +0200, Thibaut Pouzet wrote:
> There is one that remains expired, despite all the efforts I put into
> renewing it. This is the one used for the pki-ca administration pages
> reachable on ports 9443, 9444 and 9445. Here is its status after trying
> to resubmit it :
> getcert resubmit -i 20150511145941 -K HTTP/ipa_server
> getcert list -i 20150511145941
> Number of certificates and requests being tracked: 9.
> Request ID '20150511145941':
> status: CA_UNREACHABLE
> ca-error: Server at https://ipa_server/ipa/xml failed request,
> will retry: 4301 (RPC failed at server. Certificate operation cannot be
> completed: FAILURE (Invalid Request)).
> stuck: no
> key pair storage:
> cert-pki-ca',token='NSS Certificate DB',pin='1234'
> cert-pki-ca',token='NSS Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=ipa_domain
> subject: CN=ipa_server,O=ipa_domain
> expires: 2015-04-09 04:58:33 UTC
> key usage:
> eku: id-kp-serverAuth
> pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
The request settings you've got there don't quite look like the settings
for the certificate I have in the same place on my system.
The CA we use for that one is usually 'dogtag-ipa-renew-agent', and
since it's a CA-specific certificate (i.e., internal to Dogtag) rather
than a full-blown IPA-managed service, I wouldn't expect it to have a
Kerberos principal name associated with it.
Can you try
getcert resubmit -d /var/lib/pki-ca/alias -n 'Server-Cert cert-pki-ca' -c
dogtag-ipa-renew-agent -K ""
to change both the CA which is used, and to remove the principal name
from the signing request?
My IPA server (the same version of both it and Dogtag that you're
running) didn't complain when I tried it the way you're doing it, so if
the "invalid token" exception is being caused by something else, then
this might not help. But we can at least rule these things out.
One other thing I would check is if the PIN that certmonger has for the
certificate's private key matches the value listed for "internal" (not
"internaldb") in /var/lib/pki-ca/conf/password.conf, and that supplying
that value when "certutil -K -d /var/lib/pki-ca/alias" asks for one
allows the database to be decrypted so that its contents can be listed.
If they don't agree, or certutil fails to list the database's contents,
then one or both of them is incorrect about the database's password.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project