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



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


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

2013-05-02 Thread Toasted Penguin
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.
Request ID '20110706215109':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-CTIDATA-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-CTIDATA-NET/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-CTIDATA-NET',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-08-23 20:20:10 UTC
eku: id-kp-serverAuth
track: yes
auto-renew: yes
Request ID '20110706215129':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',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-08-23 20:30:21 UTC
eku: id-kp-serverAuth
track: yes
auto-renew: yes
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
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?

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