Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Nalin Dahyabhai
On Thu, May 02, 2013 at 10:59:11AM -0500, Toasted Penguin wrote:
 Running FreeIPA 2.1.4 and ran into an issue where a Server-Cert did not
 auto-renew.
 
 ipa-getcert list
 Number of certificates and requests being tracked: 4.
[snip]
 Request ID '20120615190133':
 status: CA_UNCONFIGURED
 ca-error: Error setting up ccache for local host service using default 
 keytab.
 stuck: yes
 key pair storage: 
 type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS 
 Certificate DB'
 certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
 CA: IPA
 issuer:
 subject:
 expires: unknown
 track: yes
 auto-renew: yes

That error's not expected.  Assuming there aren't any permissions-
related problems (due to SELinux policy or regular filesystem
permissions) preventing the submission helper from reading the keytab,
can you verify that hostname prints ipa01.ctidata.net, and that
kinit -k host/ipa01.ctidata.net succeeds?

 Request ID '20120925200227':
 status: GENERATING_CSR
 ca-error: Unable to determine principal name for signing request.
 stuck: no
 key pair storage: 
 type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
 Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
 certificate: 
 type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
 Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=CTIDATA.NET
 subject: CN=ipa01.ctidata.net,O=CTIDATA.NET
 expires: 2013-03-24 19:56:36 UTC
 eku: id-kp-serverAuth
 track: yes
 auto-renew: yes
 
 I verified that the IPA keytab is populated:
 
 klist -kt /etc/krb5.keytab
 Keytab name: WRFILE:/etc/krb5.keytab
 KVNO Timestamp Principal
  -
 
2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net
2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net
2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net
2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net
2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net
2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net
4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net
4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net
4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net
4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net
5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net
5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net
5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net
5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net
6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net
6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net
6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net
6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net
 
 and ran kvno host/ipa01.ctidata.net to see what the KDC shows for this
 principle:
 host/ipa01.ctidata@ctidata.net: kvno = 6
 
 Not sure what caused the ca_errors but I need to at least manually renew
 the certs and then figure out what went wrong.
 
 Any advice on what the ca_errors mean and how I can fix the issue?

The Unable to determine principal name for signing request. stems from
IPA's certificate submission API's requirement that each certificate
request include the associated Kerberos principal name, and certmonger
not knowing what value to send.

I'm guessing that there wasn't one specified with the -K option when
certmonger was told to keep an eye on the certificate, and if there was
already a certificate there, a principla name couldn't be read from it.

Based on where the certificate's being stored, it's probably intended to
be used for the HTTP service on the host, so its principal name would
be HTTP/ipa01.ctidata@ctidata.net.  If you run:
ipa-getcert resubmit -i 20120925200227 \
-K HTTP/ipa01.ctidata@ctidata.net
that should provide certmonger with the missing information and get
things going again.

HTH,

Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Nalin Dahyabhai
On Thu, May 02, 2013 at 11:45:51AM -0500, Toasted Penguin wrote:
 Nalin,
 
 Thanks for your response.  Running `hostname` does result in
 ipa01.ctidata.net and kinit -k host/ipa01.ctidata.net does also succeed.
 
 I ran ` ipa-getcert resubmit -i 20120925200227  -K HTTP/
 ipa01.ctidata@ctidata.net`
 
 and it resulted in this:
 
 Request ID '20120615190133':
 status: CA_UNCONFIGURED
 ca-error: Error setting up ccache for local host service using default 
 keytab.
 stuck: yes
 key pair storage: 
 type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS 
 Certificate DB'
 certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
 CA: IPA
 issuer:
 subject:
 expires: unknown
 track: yes
 auto-renew: yes

Can you retrieve the contents of the request and save it to a temporary
file, like so:
  reqfile=`grep -l '^id=20120615190133' /var/lib/certmonger/requests/*`
  awk '/BEGIN .*REQ/,/END .*REQ/ {sub(^( |csr=),);print}' $reqfile \
  ~/req.csr

And then try to manually submit it to the server for signing, in the way
that certmonger would, like so:
  /usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr

Hopefully the error output there will give us more information about
what's going on when the submission helper's failing to set up a ccache.

If it manages to get past that point, I expect it to fail because you
hopefully don't have a principal named bogus defined on the local
host.  But at that point we'll have gotten past errors creating the
ccache, and we'll have to find another way to figure out why it failed
here.

As an aside, we provide better information for this error in the
ca-error note with later versions than you appear to have, so tracking
down this information won't always be this complicated.

 Request ID '20120925200227':
 status: CA_UNREACHABLE
 ca-error: Server failed request, will retry: -504 (libcurl failed to
 execute the HTTP POST transaction, explaining:  Peer certificate cannot be
 authenticated with known CA certificates).
 stuck: yes
 key pair storage:
 type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
 certificate:
 type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
 Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=CTIDATA.NET
 subject: CN=ipa01.ctidata.net,O=CTIDATA.NET
 expires: 2013-03-24 19:56:36 UTC
 eku: id-kp-serverAuth
 track: yes
 auto-renew: yes

There's an error verifying the server's certificate using the local copy
of the CA certificate in /etc/ipa/ca.crt.  Is it also expired?

Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Toasted Penguin
Here is the output from the submit:

 /usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr
Submitting request to https://ipa01.ctidata.net/ipa/xml;.
Fault -504: (libcurl failed to execute the HTTP POST transaction,
explaining:  Peer certificate cannot be authenticated with known CA
certificates).
Server failed request, will retry: -504 (libcurl failed to execute the HTTP
POST transaction, explaining:  Peer certificate cannot be authenticated
with known CA certificates).

Regarding /etc/ipa/ca.crt, it isn't expired it shows its valid until July
6, 2019.


On Thu, May 2, 2013 at 12:30 PM, Nalin Dahyabhai na...@redhat.com wrote:

 On Thu, May 02, 2013 at 11:45:51AM -0500, Toasted Penguin wrote:
  Nalin,
 
  Thanks for your response.  Running `hostname` does result in
  ipa01.ctidata.net and kinit -k host/ipa01.ctidata.net does also succeed.
 
  I ran ` ipa-getcert resubmit -i 20120925200227  -K HTTP/
  ipa01.ctidata@ctidata.net`
 
  and it resulted in this:
 
  Request ID '20120615190133':
  status: CA_UNCONFIGURED
  ca-error: Error setting up ccache for local host service using default
 keytab.
  stuck: yes
  key pair storage:
 type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
 Certificate DB'
  certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
  CA: IPA
  issuer:
  subject:
  expires: unknown
  track: yes
  auto-renew: yes

 Can you retrieve the contents of the request and save it to a temporary
 file, like so:
   reqfile=`grep -l '^id=20120615190133' /var/lib/certmonger/requests/*`
   awk '/BEGIN .*REQ/,/END .*REQ/ {sub(^( |csr=),);print}' $reqfile \
   ~/req.csr

 And then try to manually submit it to the server for signing, in the way
 that certmonger would, like so:
   /usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr

 Hopefully the error output there will give us more information about
 what's going on when the submission helper's failing to set up a ccache.

 If it manages to get past that point, I expect it to fail because you
 hopefully don't have a principal named bogus defined on the local
 host.  But at that point we'll have gotten past errors creating the
 ccache, and we'll have to find another way to figure out why it failed
 here.

 As an aside, we provide better information for this error in the
 ca-error note with later versions than you appear to have, so tracking
 down this information won't always be this complicated.

  Request ID '20120925200227':
  status: CA_UNREACHABLE
  ca-error: Server failed request, will retry: -504 (libcurl failed to
  execute the HTTP POST transaction, explaining:  Peer certificate cannot
 be
  authenticated with known CA certificates).
  stuck: yes
  key pair storage:
  type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
  Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
  certificate:
  type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
  Certificate DB'
  CA: IPA
  issuer: CN=Certificate Authority,O=CTIDATA.NET
  subject: CN=ipa01.ctidata.net,O=CTIDATA.NET
  expires: 2013-03-24 19:56:36 UTC
  eku: id-kp-serverAuth
  track: yes
  auto-renew: yes

 There's an error verifying the server's certificate using the local copy
 of the CA certificate in /etc/ipa/ca.crt.  Is it also expired?

 Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Nalin Dahyabhai
On Thu, May 02, 2013 at 12:45:34PM -0500, Toasted Penguin wrote:
 Here is the output from the submit:
 
  /usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr
 Submitting request to https://ipa01.ctidata.net/ipa/xml;.
 Fault -504: (libcurl failed to execute the HTTP POST transaction,
 explaining:  Peer certificate cannot be authenticated with known CA
 certificates).
 Server failed request, will retry: -504 (libcurl failed to execute the HTTP
 POST transaction, explaining:  Peer certificate cannot be authenticated
 with known CA certificates).
 
 Regarding /etc/ipa/ca.crt, it isn't expired it shows its valid until July
 6, 2019.

Hmm, so for both cases, you're seeing errors verifying the IPA server's
certificate.  Can you double-check the certificates and that the
server's looks like it was issued by the CA?

This should more or less repeat the part of the process that's giving
libcurl trouble, and show us the certificates, too:

ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=`
openssl s_client -CAfile /etc/ipa/ca.crt \
-connect $ipahost:https -showcerts  /dev/null

Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Toasted Penguin
/etc/ipa/ca.crt was issued by O=CTIDATA.NET, CN=Certificate Authority

All the certs monitored by Certmonger show the same issuer.

Wasn't getting anything back when running the ipahost script you provided,
ran  ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=` and echo
$ipahost shows nothing so I just ran the openssl section manually:

openssl s_client -CAfile /etc/ipa/ca.crt -connect ipa01.ctidata.net:https
-showcerts  /dev/null

Results:
CONNECTED(0003)
depth=1 O = CTIDATA.NET, CN = Certificate Authority
verify return:1
depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net
verify error:num=10:certificate has expired
notAfter=Mar 24 19:56:36 2013 GMT
verify return:1
depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net
notAfter=Mar 24 19:56:36 2013 GMT
verify return:1
---
Certificate chain
 0 s:/O=CTIDATA.NET/CN=ipa01.ctidata.net
   i:/O=CTIDATA.NET/CN=Certificate Authority
-BEGIN CERTIFICATE-
#
-END CERTIFICATE-
 1 s:/O=CTIDATA.NET/CN=Certificate Authority
   i:/O=CTIDATA.NET/CN=Certificate Authority
-BEGIN CERTIFICATE-

-END CERTIFICATE-
---
Server certificate
subject=/O=CTIDATA.NET/CN=ipa01.ctidata.net
issuer=/O=CTIDATA.NET/CN=Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 1959 bytes and written 463 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID: #
Session-ID-ctx:
Master-Key: 
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1367518514
Timeout   : 300 (sec)
Verify return code: 10 (certificate has expired)
---
DONE




On Thu, May 2, 2013 at 12:53 PM, Nalin Dahyabhai na...@redhat.com wrote:

 On Thu, May 02, 2013 at 12:45:34PM -0500, Toasted Penguin wrote:
  Here is the output from the submit:
 
   /usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr
  Submitting request to https://ipa01.ctidata.net/ipa/xml;.
  Fault -504: (libcurl failed to execute the HTTP POST transaction,
  explaining:  Peer certificate cannot be authenticated with known CA
  certificates).
  Server failed request, will retry: -504 (libcurl failed to execute the
 HTTP
  POST transaction, explaining:  Peer certificate cannot be authenticated
  with known CA certificates).
 
  Regarding /etc/ipa/ca.crt, it isn't expired it shows its valid until July
  6, 2019.

 Hmm, so for both cases, you're seeing errors verifying the IPA server's
 certificate.  Can you double-check the certificates and that the
 server's looks like it was issued by the CA?

 This should more or less repeat the part of the process that's giving
 libcurl trouble, and show us the certificates, too:

 ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=`
 openssl s_client -CAfile /etc/ipa/ca.crt \
 -connect $ipahost:https -showcerts  /dev/null

 Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Nalin Dahyabhai
On Thu, May 02, 2013 at 01:23:04PM -0500, Toasted Penguin wrote:
 /etc/ipa/ca.crt was issued by O=CTIDATA.NET, CN=Certificate Authority
 
 All the certs monitored by Certmonger show the same issuer.

Ok, good.  (If that hadn't been the case, I wouldn't have had an
explanation to offer.)

 Wasn't getting anything back when running the ipahost script you provided,
 ran  ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=` and echo
 $ipahost shows nothing so I just ran the openssl section manually:

Hmm.  Curious.  That might be a leftover from having different releases
installed at various times on my test box.  Thanks for continuing on.

 openssl s_client -CAfile /etc/ipa/ca.crt -connect ipa01.ctidata.net:https
 -showcerts  /dev/null
 
 Results:
 CONNECTED(0003)
 depth=1 O = CTIDATA.NET, CN = Certificate Authority
 verify return:1
 depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net
 verify error:num=10:certificate has expired
 notAfter=Mar 24 19:56:36 2013 GMT
 verify return:1
 depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net
 notAfter=Mar 24 19:56:36 2013 GMT
 verify return:1
 ---
 Certificate chain
  0 s:/O=CTIDATA.NET/CN=ipa01.ctidata.net
i:/O=CTIDATA.NET/CN=Certificate Authority
 -BEGIN CERTIFICATE-
 #
 -END CERTIFICATE-
  1 s:/O=CTIDATA.NET/CN=Certificate Authority
i:/O=CTIDATA.NET/CN=Certificate Authority
 -BEGIN CERTIFICATE-
 
 -END CERTIFICATE-
 ---
 Server certificate
 subject=/O=CTIDATA.NET/CN=ipa01.ctidata.net
 issuer=/O=CTIDATA.NET/CN=Certificate Authority
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1959 bytes and written 463 bytes
 ---
 New, TLSv1/SSLv3, Cipher is AES256-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 Cipher: AES256-SHA
 Session-ID: #
 Session-ID-ctx:
 Master-Key: 
 Key-Arg   : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1367518514
 Timeout   : 300 (sec)
 Verify return code: 10 (certificate has expired)
 ---
 DONE

Yup, that's the problem: the IPA server's certificate wasn't able to be
replaced while it was still valid, and now it can no longer ask itself
for a new one.

With 2.1.4, I think the simplest way to sort this is to stop the
services (ipactl stop; service certmonger stop), roll the system date
back, start the services up again, possibly use 'ipa-getcert resubmit'
to force updating (it should happen automatically, but forcing it to
happen a second time won't hurt).  Then shut things down, set the
correct time on the clock, and bring everything back up again.

Hopefully there's a smarter way to do it, but I'm blanking on it if
there is one.

HTH,

Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Toasted Penguin
Yes that helped fix 2012092520027 (thank you!!)

But I am still seeing an error with:

Request ID '20120615190133':
status: CA_UNCONFIGURED
ca-error: Error setting up ccache for local host service using default
keytab.
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
track: yes
auto-renew: yes

I noticed that the request ID doesn't show up
in /var/lib/certmonger/requests/, does that make a difference?

David


On Thu, May 2, 2013 at 2:35 PM, Nalin Dahyabhai na...@redhat.com wrote:

 On Thu, May 02, 2013 at 01:23:04PM -0500, Toasted Penguin wrote:
  /etc/ipa/ca.crt was issued by O=CTIDATA.NET, CN=Certificate Authority
 
  All the certs monitored by Certmonger show the same issuer.

 Ok, good.  (If that hadn't been the case, I wouldn't have had an
 explanation to offer.)

  Wasn't getting anything back when running the ipahost script you
 provided,
  ran  ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=` and echo
  $ipahost shows nothing so I just ran the openssl section manually:

 Hmm.  Curious.  That might be a leftover from having different releases
 installed at various times on my test box.  Thanks for continuing on.

  openssl s_client -CAfile /etc/ipa/ca.crt -connect ipa01.ctidata.net:
 https
  -showcerts  /dev/null
 
  Results:
  CONNECTED(0003)
  depth=1 O = CTIDATA.NET, CN = Certificate Authority
  verify return:1
  depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net
  verify error:num=10:certificate has expired
  notAfter=Mar 24 19:56:36 2013 GMT
  verify return:1
  depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net
  notAfter=Mar 24 19:56:36 2013 GMT
  verify return:1
  ---
  Certificate chain
   0 s:/O=CTIDATA.NET/CN=ipa01.ctidata.net
 i:/O=CTIDATA.NET/CN=Certificate Authority
  -BEGIN CERTIFICATE-
  #
  -END CERTIFICATE-
   1 s:/O=CTIDATA.NET/CN=Certificate Authority
 i:/O=CTIDATA.NET/CN=Certificate Authority
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
  ---
  Server certificate
  subject=/O=CTIDATA.NET/CN=ipa01.ctidata.net
  issuer=/O=CTIDATA.NET/CN=Certificate Authority
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 1959 bytes and written 463 bytes
  ---
  New, TLSv1/SSLv3, Cipher is AES256-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1
  Cipher: AES256-SHA
  Session-ID: #
  Session-ID-ctx:
  Master-Key: 
  Key-Arg   : None
  Krb5 Principal: None
  PSK identity: None
  PSK identity hint: None
  Start Time: 1367518514
  Timeout   : 300 (sec)
  Verify return code: 10 (certificate has expired)
  ---
  DONE

 Yup, that's the problem: the IPA server's certificate wasn't able to be
 replaced while it was still valid, and now it can no longer ask itself
 for a new one.

 With 2.1.4, I think the simplest way to sort this is to stop the
 services (ipactl stop; service certmonger stop), roll the system date
 back, start the services up again, possibly use 'ipa-getcert resubmit'
 to force updating (it should happen automatically, but forcing it to
 happen a second time won't hurt).  Then shut things down, set the
 correct time on the clock, and bring everything back up again.

 Hopefully there's a smarter way to do it, but I'm blanking on it if
 there is one.

 HTH,

 Nalin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Expired certs not auto renewed by Cermonger

2013-05-02 Thread Rob Crittenden

Toasted Penguin wrote:

Yes that helped fix 2012092520027 (thank you!!)

But I am still seeing an error with:

Request ID '20120615190133':
status: CA_UNCONFIGURED
ca-error: Error setting up ccache for local host service using default
keytab.
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
track: yes
auto-renew: yes

I noticed that the request ID doesn't show up
in /var/lib/certmonger/requests/, does that make a difference?


The request ID usually, but not always matches the name of the request 
files.


We don't usually issue a Server-Cert for an IPA server. Could this be a 
remnant of an older client install?


Is there a Server-Cert in /etc/pki/nssdb? certutil -L -d /etc/pki/nssdb

rob


David


On Thu, May 2, 2013 at 2:35 PM, Nalin Dahyabhai na...@redhat.com
mailto:na...@redhat.com wrote:

On Thu, May 02, 2013 at 01:23:04PM -0500, Toasted Penguin wrote:
  /etc/ipa/ca.crt was issued by O=CTIDATA.NET http://CTIDATA.NET,
CN=Certificate Authority
 
  All the certs monitored by Certmonger show the same issuer.

Ok, good.  (If that hadn't been the case, I wouldn't have had an
explanation to offer.)

  Wasn't getting anything back when running the ipahost script you
provided,
  ran  ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=`
and echo
  $ipahost shows nothing so I just ran the openssl section manually:

Hmm.  Curious.  That might be a leftover from having different releases
installed at various times on my test box.  Thanks for continuing on.

  openssl s_client -CAfile /etc/ipa/ca.crt -connect
ipa01.ctidata.net:https
  -showcerts  /dev/null
 
  Results:
  CONNECTED(0003)
  depth=1 O = CTIDATA.NET http://CTIDATA.NET, CN = Certificate
Authority
  verify return:1
  depth=0 O = CTIDATA.NET http://CTIDATA.NET, CN =
ipa01.ctidata.net http://ipa01.ctidata.net
  verify error:num=10:certificate has expired
  notAfter=Mar 24 19:56:36 2013 GMT
  verify return:1
  depth=0 O = CTIDATA.NET http://CTIDATA.NET, CN =
ipa01.ctidata.net http://ipa01.ctidata.net
  notAfter=Mar 24 19:56:36 2013 GMT
  verify return:1
  ---
  Certificate chain
   0 s:/O=CTIDATA.NET/CN=ipa01.ctidata.net
http://CTIDATA.NET/CN=ipa01.ctidata.net
 i:/O=CTIDATA.NET/CN=Certificate
http://CTIDATA.NET/CN=Certificate Authority
  -BEGIN CERTIFICATE-
  #
  -END CERTIFICATE-
   1 s:/O=CTIDATA.NET/CN=Certificate
http://CTIDATA.NET/CN=Certificate Authority
 i:/O=CTIDATA.NET/CN=Certificate
http://CTIDATA.NET/CN=Certificate Authority
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
  ---
  Server certificate
  subject=/O=CTIDATA.NET/CN=ipa01.ctidata.net
http://CTIDATA.NET/CN=ipa01.ctidata.net
  issuer=/O=CTIDATA.NET/CN=Certificate
http://CTIDATA.NET/CN=Certificate Authority
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 1959 bytes and written 463 bytes
  ---
  New, TLSv1/SSLv3, Cipher is AES256-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1
  Cipher: AES256-SHA
  Session-ID: #
  Session-ID-ctx:
  Master-Key: 
  Key-Arg   : None
  Krb5 Principal: None
  PSK identity: None
  PSK identity hint: None
  Start Time: 1367518514
  Timeout   : 300 (sec)
  Verify return code: 10 (certificate has expired)
  ---
  DONE

Yup, that's the problem: the IPA server's certificate wasn't able to be
replaced while it was still valid, and now it can no longer ask itself
for a new one.

With 2.1.4, I think the simplest way to sort this is to stop the
services (ipactl stop; service certmonger stop), roll the system date
back, start the services up again, possibly use 'ipa-getcert resubmit'
to force updating (it should happen automatically, but forcing it to
happen a second time won't hurt).  Then shut things down, set the
correct time on the clock, and bring everything back up again.

Hopefully there's a smarter way to do it, but I'm blanking on it if
there is one.

HTH,

Nalin




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users