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:
>>>     Data:
>>>         Version: 0 (0x0)
>>>         Subject: O=ipa_domain, CN=ipa_server
>>>         Subject Public Key Info:
>>>             Public Key Algorithm: rsaEncryption
>>>                 Public-Key: (2048 bit)
>>>                 Modulus:
>>>                     00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a:
>>>                     04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8:
>>>                     77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a:
>>>                     93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22:
>>>                     0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e:
>>>                     67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d:
>>>                     53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2:
>>>                     d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31:
>>>                     38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6:
>>>                     00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88:
>>>                     f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60:
>>>                     c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69:
>>>                     04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30:
>>>                     b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e:
>>>                     0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4:
>>>                     53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9:
>>>                     62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28:
>>>                     1b:fb
>>>                 Exponent: 65537 (0x10001)
>>>         Attributes:
>>>             a0:00
>>>     Signature Algorithm: sha256WithRSAEncryption
>>>          10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43:
>>>          bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58:
>>>          87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20:
>>>          dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85:
>>>          9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8:
>>>          69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1:
>>>          ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53:
>>>          46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be:
>>>          db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36:
>>>          ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0:
>>>          93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0:
>>>          8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e:
>>>          60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f:
>>>          05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9:
>>>          3e:cc:cb:d8
>>>
>>> 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"
> tomcatjss-2.1.0-3.el6.noarch
> certmonger-0.75.13-1.el6.x86_64
> jss-4.2.6-24.el6.x86_64
> 
>>
>> 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?
>>
>>   jss.configDir=/var/lib/pki-ca/alias/
>>   jss.enable=true
>>   jss.secmodName=secmod.db
>>
> 
> 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.
>>
>> Nalin
>>
> 
> 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.
> 
> Cheers,
> 

Hi,

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
        status: loaded

         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 :
        status: CA_UNREACHABLE
        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...

Cheers,

-- 
Thibaut Pouzet
Lyra Network
Ingénieur Systèmes et Réseaux
(+33) 5 31 22 40 08
www.lyra-network.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to