[Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)
Thibaut Pouzet
thibaut.pouzet at lyra-network.com
Tue May 12 16:39:13 UTC 2015
Le 12/05/2015 18:09, Nalin Dahyabhai a écrit :
> 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:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
>> cert-pki-ca',token='NSS Certificate DB',pin='1234'
>> certificate:
>> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
>> 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:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> 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 ""
After running this request for the first time, I have this output :
Request ID '20150511145941':
status: NEED_TO_SUBMIT
ca-error: Error 7 connecting to
http://ipa_server:9180/ca/ee/ca/profileSubmit: Couldn't connect to server.
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin='1234'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=ipa_domain
subject: CN=ipa_server,O=ipa_domain
expires: 2015-04-09 04:58:33 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
>
> to change both the CA which is used, and to remove the principal name
> from the signing request?
>
After this, I tried to resubmit it, and got this status :
Request ID '20150511145941':
status: MONITORING
ca-error: Server at
"http://ipa_server:9180/ca/ee/ca/profileSubmit" replied: Invalid Request
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin='1234'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=ipa_domain
subject: CN=ipa_server,O=ipa_domain
expires: 2015-04-09 04:58:33 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
I ran your command a second time ('just to be sure'), and did not got
the "Couldn't connect to server" error message, only the "Invalid
Request" one in the status of the certificate.
> 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.
>
I can read the content of the database using the pin that is inside this
file (which is the same pin as the one inside certmonger)
> HTH,
>
> Nalin
>
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 !
Cheers
--
Thibaut Pouzet
Lyra Network
Ingénieur Systèmes et Réseaux
(+33) 5 31 22 40 08
www.lyra-network.com
More information about the Freeipa-users
mailing list