Le 13/05/2015 10:15, Thibaut Pouzet a écrit :
> Le 12/05/2015 20:11, Nalin Dahyabhai a écrit :
>> On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote:
>>> After doing what you recommended, the CSR have changed in the debug log :
>>> Certificate Request:
>>> Version: 0 (0x0)
>>> Subject: O=ipa_domain, CN=ipa_server
>>> Subject Public Key Info:
>>> Public Key Algorithm: rsaEncryption
>>> Public-Key: (2048 bit)
>>> Exponent: 65537 (0x10001)
>>> Signature Algorithm: sha256WithRSAEncryption
>>> There is no more this weird "friendlyName :unable to print
>>> attribute" thing, but the NoSuchTokenException is still in the debug log
>>> of pki-ca
>>> Thank you for you answer though, we've still made some progress in
>>> identifying that I messed the CA used for this certificate !
>> Hmm, so what you've got there looks pretty normal for a renewal request.
>> Just to rule out a problem with the request's signature or the encoding
>> of the subject name in the request (the latter is a bug in versions of
>> certmonger before 0.72), can you check the version of the certmonger
>> package and show us the base64-encoded form of the signing request?
> Before going further and asking the ML, I got these packages updated
> 'just in case' :
> rpm -qa | egrep "certmonger|jss"
>> I'm just about grasping at straws here, but the NoSuchTokenException
>> exception appears to be coming from the jss library, and is thrown when
>> it can't find the software module that is used for accessing the
>> server's keys. Can you verify that your /etc/pki-ca/CS.cfg file
>> contains these lines?
> These lines are exactly as is inside the CS.cfg file
>> Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I
>> don't have one. The Dogtag logic looks like it would try to use one set
>> there rather than the default, but letting it use the default looks like
>> the intended way of doing things.
> I cannot find this line, this is all I've got that seems somehow related
> to a token notion :
> fgrep token /etc/pki-ca/CS.cfg
> ca.audit_signing.tokenname=Internal Key Storage Token
> ca.ocsp_signing.tokenname=Internal Key Storage Token
> ca.signing.tokenname=Internal Key Storage Token
> ca.sslserver.tokenname=Internal Key Storage Token
> ca.subsystem.tokenname=Internal Key Storage Token
> cloning.module.token=Internal Key Storage Token
>> Which version of the jss and tomcatjss packages are installed? I'm
>> using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here.
>> If none of this turns up anything, then I'm going to have to defer to
>> the Dogtag team, too.
> I do not wish to give away too much information on this ML, so I will
> send the base64 CSR and CS.cfg file to you personally. I am sorry for
> the other people watching this discussions... I will take care to submit
> relevant information if anything is found with this.
It appeared that the NSS DB had fips enabled due to the troubleshooting
of an old problem :
# modutil -dbdir /var/lib/pki-ca/alias/ -list
Listing of PKCS #11 Modules
1. NSS Internal FIPS PKCS #11 Module
slots: 1 slot attached
slot: NSS FIPS 140-2 User Private Key Services
token: NSS FIPS 140-2 Certificate DB
I disabled it : modutil -dbdir /var/lib/pki-ca/alias -fips false
And no longer have the stack trace in the debug logs while re-sumbitting
the certificate with certmonger.
This is a first step in this certificate renewal, as I still cannot
renew it, I have a new error :
ca-error: Error 60 connecting to
https://ipa_server:9443/ca/agent/ca/profileReview: Peer certificate
cannot be authenticated with known CA certificates.
This looks like a chicken and egg problem, the certificate served on
ipa_server:9443 is the one that needs to be renewed. I tried to step
back in time when the certificate was still valid with no luck.
So if anyone has an idea here...
Ingénieur Systèmes et Réseaux
(+33) 5 31 22 40 08
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project