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,

-- 
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