Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-06-09 Thread Thibaut Pouzet
Le 05/06/2015 22:19, Endi Sukma Dewata a écrit :
 On 5/19/2015 3:54 AM, Thibaut Pouzet wrote:
 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,
 
 Hi,
 
 Is this still a problem? Per discussion with Rob it doesn't seem to be
 an issue with Dogtag itself.
 
 I suppose you are following this instruction:
 http://www.freeipa.org/page/Howto/CA_Certificate_Renewal
 
 Could you post the full getcert list output? Also after you reset the
 clock back and try the renewal again could you post the error messages
 that you get?
 
 Hopefully the IPA team will be able to troubleshoot further. Thanks.
 

Hi Endi,

Indeed, this is still a problem for this server. I did not had any new
idea on how to troubleshoot this issue unfortunately... Here is what you
asked :

With ntp running, date is now :

$ sudo getcert list -c dogtag-ipa-renew-agent
Number of certificates and requests being tracked: 9.
Request ID '20150511123414':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='640188994674'
certificate:
type=NSSDB,='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=ipa_domain
subject: CN=CA Audit,O=ipa_domain
expires: 2017-04-10 05:34:30 UTC
key usage: digitalSignature,nonRepudiation
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150511123614':
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.
stuck: no
key pair storage:
type=NSSDB,='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin='640188994674'
certificate:
type=NSSDB,='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=ipa_domain
subject: CN=CA Subsystem,O=ipa_domain
expires: 2015-04-09 04:58:34 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150511123705':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate
DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=ipa_domain
subject: CN=IPA RA,O=ipa_domain
expires: 2017-04-18 07:11:38 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20150513074100':
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.
stuck: no
key pair storage:
type=NSSDB,='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin='640188994674'
certificate:
type=NSSDB,='/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
 

Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-06-09 Thread Thibaut Pouzet
Le 09/06/2015 15:50, Rob Crittenden a écrit :
 Thibaut Pouzet wrote:
 Le 05/06/2015 22:19, Endi Sukma Dewata a écrit :
 Is this still a problem? Per discussion with Rob it doesn't seem to be
 an issue with Dogtag itself.

 I suppose you are following this instruction:
 http://www.freeipa.org/page/Howto/CA_Certificate_Renewal

 Could you post the full getcert list output? Also after you reset the
 clock back and try the renewal again could you post the error messages
 that you get?

 Hopefully the IPA team will be able to troubleshoot further. Thanks.


 Hi Endi,

 Indeed, this is still a problem for this server. I did not had any new
 idea on how to troubleshoot this issue unfortunately... Here is what you
 asked :

 With ntp running, date is now :

 $ sudo getcert list -c dogtag-ipa-renew-agent
 
 Thanks for including the full output. Are you restarting IPA when
 setting the date back? If not, you need to.
 
 rob

Hi,

Restarting IPA or not do not change anything : no logs, same error in
getcert list

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


Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-06-09 Thread Rob Crittenden

Thibaut Pouzet wrote:

Le 05/06/2015 22:19, Endi Sukma Dewata a écrit :

Is this still a problem? Per discussion with Rob it doesn't seem to be
an issue with Dogtag itself.

I suppose you are following this instruction:
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal

Could you post the full getcert list output? Also after you reset the
clock back and try the renewal again could you post the error messages
that you get?

Hopefully the IPA team will be able to troubleshoot further. Thanks.



Hi Endi,

Indeed, this is still a problem for this server. I did not had any new
idea on how to troubleshoot this issue unfortunately... Here is what you
asked :

With ntp running, date is now :

$ sudo getcert list -c dogtag-ipa-renew-agent


Thanks for including the full output. Are you restarting IPA when 
setting the date back? If not, you need to.


rob

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


Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-06-05 Thread Endi Sukma Dewata

On 5/19/2015 3:54 AM, Thibaut Pouzet wrote:

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,


Hi,

Is this still a problem? Per discussion with Rob it doesn't seem to be 
an issue with Dogtag itself.


I suppose you are following this instruction:
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal

Could you post the full getcert list output? Also after you reset the 
clock back and try the renewal again could you post the error messages 
that you get?


Hopefully the IPA team will be able to troubleshoot further. Thanks.

--
Endi S. Dewata

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


Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-19 Thread Thibaut Pouzet
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 

Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-13 Thread Thibaut Pouzet
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 

Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-12 Thread Martin Kosek
On 05/11/2015 05:14 PM, Thibaut Pouzet wrote:
 Hi !
 
 I am running into a weird problem with my IPA Server, and the
 certificates management. My setup is :
 CentOS 6.6
 pki-ca-9.0.3-38.el6_6.noarch
 ipa-server-3.0.0-42.el6.centos.x86_64
 Linux ipa_server 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29
 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 
 The server has been installed two years ago, and all the certificates on
 the master server expired this month. (2 year validity). Apparently,
 they were not properly tracked by certmonger, so they were not renewed.
 
 By doing some getcert stop-tracking, then getcert start-tracking , I
 was able to track 8 of the 9 certificates that I can display with
 getcert list on this server.
 
 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
 
 
 I tried to stop tracking it, and then tracking it again, with no luck :
 getcert start-tracking -d /var/lib/pki-ca/alias -n subsystemCert
 cert-pki-ca -t NSS Certificate DB -P 1234 -r -c IPA
 
 I changed the trust settings as well, still not working :
 sh-4.1# certutil -M -n Server-Cert cert-pki-ca -d
 /var/lib/pki-ca/alias -t u,u,Pu
 
 sh-4.1# certutil -L -d /var/lib/pki-ca/alias
 Certificate Nickname Trust
 Attributes
 SSL,S/MIME,JAR/XPI
 ocspSigningCert cert-pki-ca  u,u,u
 subsystemCert cert-pki-cau,u,u
 auditSigningCert cert-pki-ca u,u,Pu
 caSigningCert cert-pki-caCTu,Cu,Cu
 Server-Cert cert-pki-ca  u,u,Pu
 
 However, I find this error in different places :
 ca-error: Server at http://ipa_server:9180/ca/ee/ca/profileSubmit;
 replied: Invalid Request
 
 sh-4.1# ipa user-show admin
 ipa: ERROR: Missing or invalid HTTP Referer, https://ipa_server/ipa/xml
 
 Sometimes, I also get it with ipa cert-show 1, sometimes I don't.
 
 Sometimes its status changes even though I don't think I've done anything :
 ca-error: Server at https://ipa_server/ipa/xml failed request, will
 retry: 911 (RPC failed at server.  Missing or invalid HTTP Referer,
 https://ipa_server/ipa/xml).
 
 And I can find inside /var/log/pki-ca/debug these lines :
 [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10:
 signature verification enabled
 [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10
 org.mozilla.jss.NoSuchTokenException
 [11/May/2015:20:38:49][http-9180-1]: EnrollProfile: parsePKCS10
 restoring thread token
 Invalid Request
 at
 com.netscape.cms.profile.common.EnrollProfile.parsePKCS10(EnrollProfile.java:953)
 at
 com.netscape.cms.profile.common.EnrollProfile.createRequests(EnrollProfile.java:102)
 at
 com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:1001)
 at
 com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:501)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFilter.java:176)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at
 

Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-12 Thread Nalin Dahyabhai
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 

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.

HTH,

Nalin

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


Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-12 Thread Nalin Dahyabhai
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?

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

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.

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

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


Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-12 Thread Thibaut Pouzet
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 

Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-12 Thread Endi Sukma Dewata

On 5/12/2015 1:11 PM, Nalin Dahyabhai wrote:

On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote:

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?

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

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.

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 think you're on to something. The Invalid Request message is 
misleading. The actual error is NoSuchTokenException and it happens 
before the PKCS10 request is parsed. So yes, we need to check the 
ca.requestVerify.token parameter.


--
Endi S. Dewata

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


Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

2015-05-12 Thread Endi Sukma Dewata

On 5/12/2015 11:39 AM, Thibaut Pouzet wrote:

There is no more this weird friendlyName :unable to print
attribute thing, but the NoSuchTokenException is still in the debug log
of pki-ca


Hi,

Could you post or email me the CS.cfg and the log files of the CA? Thanks.

--
Endi S. Dewata

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