Hello all, I had an issue a short while ago with a replica which turned out to be an expired certificate which I renewed and all seemed good.
Seemed...
It now appears that although the certificate renewed as seen by getcert -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki services won't start unless I set the date to before the certificate expired, and even then sometimes the httpd error_log shows: Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. and the service fails to start.
I've tried resubmitting the certificate, and it doesn't seem to throw an error, but it doesn't update /alias either. Trying to access the server via the web page shows the old certificate still in use. I see the same certificate error with the replica server, which was freshly rebuilt and added last week. I've doubtless dug further into the hole trying to troubleshoot this, so I probably need to start from the beginning again, and a pointer in the right direction would be a great help!
A getcert list shows all the certificates expiry dates well into the future.
How can I get the certs back in sync? I've found a few guides and most seem to be for earlier versions, and I'm not sure if they're still current.
I can post whatever logs you think will help, I'm afraid I'm not familiar enough with them all to tell which are the most relevant. Is there a guide for the logs?
Thanks for any help you can give,
Thomas
On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via FreeIPA-users wrote:
Hello all, I had an issue a short while ago with a replica which turned out to be an expired certificate which I renewed and all seemed good.
Seemed...
It now appears that although the certificate renewed as seen by getcert -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki services won't start unless I set the date to before the certificate expired, and even then sometimes the httpd error_log shows: Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can start until the problem can be resolved. and the service fails to start.
Hi Thomas,
Can you please show `getcert list` output on the server in question, as well as the output of
certutil -d /etc/httpd/alias -L Server-Cert
and
certutil -d /etc/pki/pki-tomcatd/alias -L <nickname>
for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB.
And Certmonger journal output. And pki debug log /var/log/pki/pki-tomcat/ca/debug.
It is strange that `getcert list' shows an up to date certificate while the actual certificate that is being tracked is expired...
Thanks, Fraser
I've tried resubmitting the certificate, and it doesn't seem to throw an error, but it doesn't update /alias either. Trying to access the server via the web page shows the old certificate still in use. I see the same certificate error with the replica server, which was freshly rebuilt and added last week. I've doubtless dug further into the hole trying to troubleshoot this, so I probably need to start from the beginning again, and a pointer in the right direction would be a great help!
A getcert list shows all the certificates expiry dates well into the future.
How can I get the certs back in sync? I've found a few guides and most seem to be for earlier versions, and I'm not sure if they're still current.
I can post whatever logs you think will help, I'm afraid I'm not familiar enough with them all to tell which are the most relevant. Is there a guide for the logs?
Thanks for any help you can give,
Thomas
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Hello,
I think this is everything (domain name changed to protect the guilty!):
I pulled the same on the replica, which appears to be playing up too in a similar fashion.
I did just notice the date on the replica is out, I never set it back when I was trying to get the cert to renew.
Let me know if you need anything else.
Thanks,
Thomas
On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via FreeIPA-users wrote:
Hello all, I had an issue a short while ago with a replica which turned out to be an expired certificate which I renewed and all seemed good.
Seemed...
It now appears that although the certificate renewed as seen by getcert -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki services won't start unless I set the date to before the certificate expired, and even then sometimes the httpd error_log shows: Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts
off"
to nss.conf so the server can start until the problem can be resolved. and the service fails to start.
Hi Thomas,
Can you please show `getcert list` output on the server in question, as well as the output of
certutil -d /etc/httpd/alias -L Server-Cert
and
certutil -d /etc/pki/pki-tomcatd/alias -L <nickname>
for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB.
And Certmonger journal output. And pki debug log /var/log/pki/pki-tomcat/ca/debug.
It is strange that `getcert list' shows an up to date certificate while the actual certificate that is being tracked is expired...
Thanks, Fraser
I've tried resubmitting the certificate, and it doesn't seem to throw an error, but it doesn't update /alias either. Trying to access the server via the web page shows the old certificate still in use. I see the same certificate error with the replica server, which was
freshly
rebuilt and added last week. I've doubtless dug further into the hole trying to troubleshoot this, so
I
probably need to start from the beginning again, and a pointer in the
right
direction would be a great help!
A getcert list shows all the certificates expiry dates well into the
future.
How can I get the certs back in sync? I've found a few guides and most
seem
to be for earlier versions, and I'm not sure if they're still current.
I can post whatever logs you think will help, I'm afraid I'm not familiar enough with them all to tell which are the most relevant. Is there a
guide
for the logs?
Thanks for any help you can give,
Thomas
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
After some fiddling with dates some more I seem to have the HTTPD cert in sync, however it appears the cert signing cert is expired.
named also says it's starting, but doesn't seem to want to respond.
I don't have time to dig into it more tonight, but let me know what other information or tests I can run and I'll get them posted tomorrow.
Thanks all.
Thomas
On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby xrs444@xrs444.net wrote:
Hello,
I think this is everything (domain name changed to protect the guilty!):
I pulled the same on the replica, which appears to be playing up too in a similar fashion.
I did just notice the date on the replica is out, I never set it back when I was trying to get the cert to renew.
Let me know if you need anything else.
Thanks,
Thomas
On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via FreeIPA-users wrote:
Hello all, I had an issue a short while ago with a replica which turned out to be
an
expired certificate which I renewed and all seemed good.
Seemed...
It now appears that although the certificate renewed as seen by getcert -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki services won't start unless I set the date to before the certificate expired, and even then sometimes the httpd error_log shows: Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts
off"
to nss.conf so the server can start until the problem can be resolved. and the service fails to start.
Hi Thomas,
Can you please show `getcert list` output on the server in question, as well as the output of
certutil -d /etc/httpd/alias -L Server-Cert
and
certutil -d /etc/pki/pki-tomcatd/alias -L <nickname>
for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB.
And Certmonger journal output. And pki debug log /var/log/pki/pki-tomcat/ca/debug.
It is strange that `getcert list' shows an up to date certificate while the actual certificate that is being tracked is expired...
Thanks, Fraser
I've tried resubmitting the certificate, and it doesn't seem to throw an error, but it doesn't update /alias either. Trying to access the server via the web page shows the old certificate still in use. I see the same certificate error with the replica server, which was
freshly
rebuilt and added last week. I've doubtless dug further into the hole trying to troubleshoot this,
so I
probably need to start from the beginning again, and a pointer in the
right
direction would be a great help!
A getcert list shows all the certificates expiry dates well into the
future.
How can I get the certs back in sync? I've found a few guides and most
seem
to be for earlier versions, and I'm not sure if they're still current.
I can post whatever logs you think will help, I'm afraid I'm not
familiar
enough with them all to tell which are the most relevant. Is there a
guide
for the logs?
Thanks for any help you can give,
Thomas
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote:
After some fiddling with dates some more I seem to have the HTTPD cert in sync, however it appears the cert signing cert is expired.
named also says it's starting, but doesn't seem to want to respond.
I don't have time to dig into it more tonight, but let me know what other information or tests I can run and I'll get them posted tomorrow.
Thanks all.
Thomas
On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Hello, I think this is everything (domain name changed to protect the guilty!): https://pastebin.com/bF1KR7VJ
Hi Thomas,
in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format' can be easily explained: there is a typo in the directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n <nickname> (note the pki-tomcat instead of pki-tomcat*d*).
You mention that the cert signing cert is expired, can you clarify which certificate this is? Please provide the subject name, certificate nickname and location.
Flo
I pulled the same on the replica, which appears to be playing up too in a similar fashion. I did just notice the date on the replica is out, I never set it back when I was trying to get the cert to renew. Let me know if you need anything else. Thanks, Thomas On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote: On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via FreeIPA-users wrote: > Hello all, > I had an issue a short while ago with a replica which turned out to be an > expired certificate which I renewed and all seemed good. > > Seemed... > > It now appears that although the certificate renewed as seen by getcert > -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki > services won't start unless I set the date to before the certificate > expired, and even then sometimes the httpd error_log shows: > Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" > to nss.conf so the server can start until the problem can be resolved. > and the service fails to start. > Hi Thomas, Can you please show `getcert list` output on the server in question, as well as the output of certutil -d /etc/httpd/alias -L Server-Cert and certutil -d /etc/pki/pki-tomcatd/alias -L <nickname> for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. And Certmonger journal output. And pki debug log /var/log/pki/pki-tomcat/ca/debug. It is strange that `getcert list' shows an up to date certificate while the actual certificate that is being tracked is expired... Thanks, Fraser > I've tried resubmitting the certificate, and it doesn't seem to throw an > error, but it doesn't update /alias either. > Trying to access the server via the web page shows the old certificate > still in use. > I see the same certificate error with the replica server, which was freshly > rebuilt and added last week. > I've doubtless dug further into the hole trying to troubleshoot this, so I > probably need to start from the beginning again, and a pointer in the right > direction would be a great help! > > A getcert list shows all the certificates expiry dates well into the future. > > How can I get the certs back in sync? I've found a few guides and most seem > to be for earlier versions, and I'm not sure if they're still current. > > I can post whatever logs you think will help, I'm afraid I'm not familiar > enough with them all to tell which are the most relevant. Is there a guide > for the logs? > > Thanks for any help you can give, > > Thomas > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Hello Florence,
It was the Signing-Cert and the I.domain.NET IPA CA cert. By setting the clock back I managed to get those to renew, now it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud flo@redhat.com wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote:
After some fiddling with dates some more I seem to have the HTTPD cert in sync, however it appears the cert signing cert is expired.
named also says it's starting, but doesn't seem to want to respond.
I don't have time to dig into it more tonight, but let me know what other information or tests I can run and I'll get them posted tomorrow.
Thanks all.
Thomas
On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Hello, I think this is everything (domain name changed to protect the guilty!): https://pastebin.com/bF1KR7VJ
Hi Thomas,
in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format' can be easily explained: there is a typo in the directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n <nickname> (note the pki-tomcat instead of pki-tomcat*d*).
You mention that the cert signing cert is expired, can you clarify which certificate this is? Please provide the subject name, certificate nickname and location.
Flo
I pulled the same on the replica, which appears to be playing up too in a similar fashion. I did just notice the date on the replica is out, I never set it back when I was trying to get the cert to renew. Let me know if you need anything else. Thanks, Thomas On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote: On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via FreeIPA-users wrote: > Hello all, > I had an issue a short while ago with a replica which turned out to be an > expired certificate which I renewed and all seemed good. > > Seemed... > > It now appears that although the certificate renewed as seen by getcert > -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki > services won't start unless I set the date to before the certificate > expired, and even then sometimes the httpd error_log shows: > Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" > to nss.conf so the server can start until the problem can be resolved. > and the service fails to start. > Hi Thomas, Can you please show `getcert list` output on the server in
question,
as well as the output of certutil -d /etc/httpd/alias -L Server-Cert and certutil -d /etc/pki/pki-tomcatd/alias -L <nickname> for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. And Certmonger journal output. And pki debug log /var/log/pki/pki-tomcat/ca/debug. It is strange that `getcert list' shows an up to date certificate while the actual certificate that is being tracked is expired... Thanks, Fraser > I've tried resubmitting the certificate, and it doesn't seem to throw an > error, but it doesn't update /alias either. > Trying to access the server via the web page shows the old certificate > still in use. > I see the same certificate error with the replica server, which was freshly > rebuilt and added last week. > I've doubtless dug further into the hole trying to troubleshoot this, so I > probably need to start from the beginning again, and a pointer in the right > direction would be a great help! > > A getcert list shows all the certificates expiry dates well into the future. > > How can I get the certs back in sync? I've found a few guides and most seem > to be for earlier versions, and I'm not sure if they're still current. > > I can post whatever logs you think will help, I'm afraid I'm not familiar > enough with them all to tell which are the most relevant. Is there a guide > for the logs? > > Thanks for any help you can give, > > Thomas > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
On Wed, Jun 27, 2018 at 06:22:31PM -0700, Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET IPA CA cert. By setting the clock back I managed to get those to renew, now it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Thomas
Hi Thomas,
It looks like Directory Server is not accepting the subsystemCert, which Dogtag uses to authenticate to the DS.
What is the output of `certutil -d /etc/dirsrv/slapd-YOUR-DOMAIN -L` ?
Please also check that the 'userCertificate' attribute of 'uid=pkidbuser,ou=people,o=ipaca' is an exact match for the subsystemCert in the /etc/pki/pki-tomcat/alias NSSDB.
Thanks, Fraser
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud flo@redhat.com wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote:
After some fiddling with dates some more I seem to have the HTTPD cert in sync, however it appears the cert signing cert is expired.
named also says it's starting, but doesn't seem to want to respond.
I don't have time to dig into it more tonight, but let me know what other information or tests I can run and I'll get them posted tomorrow.
Thanks all.
Thomas
On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Hello, I think this is everything (domain name changed to protect the guilty!): https://pastebin.com/bF1KR7VJ
Hi Thomas,
in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format' can be easily explained: there is a typo in the directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n <nickname> (note the pki-tomcat instead of pki-tomcat*d*).
You mention that the cert signing cert is expired, can you clarify which certificate this is? Please provide the subject name, certificate nickname and location.
Flo
I pulled the same on the replica, which appears to be playing up too in a similar fashion. I did just notice the date on the replica is out, I never set it back when I was trying to get the cert to renew. Let me know if you need anything else. Thanks, Thomas On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote: On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via FreeIPA-users wrote: > Hello all, > I had an issue a short while ago with a replica which turned out to be an > expired certificate which I renewed and all seemed good. > > Seemed... > > It now appears that although the certificate renewed as seen by getcert > -list, it didn't update /etc/httpd/alias and so the httpd and tomcat-pki > services won't start unless I set the date to before the certificate > expired, and even then sometimes the httpd error_log shows: > Unable to verify certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" > to nss.conf so the server can start until the problem can be resolved. > and the service fails to start. > Hi Thomas, Can you please show `getcert list` output on the server in
question,
as well as the output of certutil -d /etc/httpd/alias -L Server-Cert and certutil -d /etc/pki/pki-tomcatd/alias -L <nickname> for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. And Certmonger journal output. And pki debug log /var/log/pki/pki-tomcat/ca/debug. It is strange that `getcert list' shows an up to date certificate while the actual certificate that is being tracked is expired... Thanks, Fraser > I've tried resubmitting the certificate, and it doesn't seem to throw an > error, but it doesn't update /alias either. > Trying to access the server via the web page shows the old certificate > still in use. > I see the same certificate error with the replica server, which was freshly > rebuilt and added last week. > I've doubtless dug further into the hole trying to troubleshoot this, so I > probably need to start from the beginning again, and a pointer in the right > direction would be a great help! > > A getcert list shows all the certificates expiry dates well into the future. > > How can I get the certs back in sync? I've found a few guides and most seem > to be for earlier versions, and I'm not sure if they're still current. > > I can post whatever logs you think will help, I'm afraid I'm not familiar > enough with them all to tell which are the most relevant. Is there a guide > for the logs? > > Thanks for any help you can give, > > Thomas > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET http://I.domain.NET IPA CA cert. By setting the clock back I managed to get those to renew, now it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET http://I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET http://I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar file used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <flo@redhat.com mailto:flo@redhat.com> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > After some fiddling with dates some more I seem to have the HTTPD cert > in sync, however it appears the cert signing cert is expired. > > named also says it's starting, but doesn't seem to want to respond. > > I don't have time to dig into it more tonight, but let me know what > other information or tests I can run and I'll get them posted tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <xrs444@xrs444.net <mailto:xrs444@xrs444.net> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>> wrote: > > Hello, > > I think this is everything (domain name changed to protect the > guilty!): > > https://pastebin.com/bF1KR7VJ > Hi Thomas, in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format' can be easily explained: there is a typo in the directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n <nickname> (note the pki-tomcat instead of pki-tomcat*d*). You mention that the cert signing cert is expired, can you clarify which certificate this is? Please provide the subject name, certificate nickname and location. Flo > I pulled the same on the replica, which appears to be playing up too > in a similar fashion. > > I did just notice the date on the replica is out, I never set it > back when I was trying to get the cert to renew. > > Let me know if you need anything else. > > Thanks, > > Thomas > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com> > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> wrote: > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via > FreeIPA-users wrote: > > Hello all, > > I had an issue a short while ago with a replica which turned > out to be an > > expired certificate which I renewed and all seemed good. > > > > Seemed... > > > > It now appears that although the certificate renewed as seen > by getcert > > -list, it didn't update /etc/httpd/alias and so the httpd and > tomcat-pki > > services won't start unless I set the date to before the > certificate > > expired, and even then sometimes the httpd error_log shows: > > Unable to verify certificate 'Server-Cert'. Add > "NSSEnforceValidCerts off" > > to nss.conf so the server can start until the problem can be > resolved. > > and the service fails to start. > > > Hi Thomas, > > Can you please show `getcert list` output on the server in question, > as well as the output of > > certutil -d /etc/httpd/alias -L Server-Cert > > and > > certutil -d /etc/pki/pki-tomcatd/alias -L <nickname> > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > And Certmonger journal output. And pki debug log > /var/log/pki/pki-tomcat/ca/debug. > > It is strange that `getcert list' shows an up to date certificate > while the actual certificate that is being tracked is expired... > > Thanks, > Fraser > > > I've tried resubmitting the certificate, and it doesn't seem > to throw an > > error, but it doesn't update /alias either. > > Trying to access the server via the web page shows the old > certificate > > still in use. > > I see the same certificate error with the replica server, > which was freshly > > rebuilt and added last week. > > I've doubtless dug further into the hole trying to > troubleshoot this, so I > > probably need to start from the beginning again, and a > pointer in the right > > direction would be a great help! > > > > A getcert list shows all the certificates expiry dates well > into the future. > > > > How can I get the certs back in sync? I've found a few guides > and most seem > > to be for earlier versions, and I'm not sure if they're still > current. > > > > I can post whatever logs you think will help, I'm afraid I'm > not familiar > > enough with them all to tell which are the most relevant. Is > there a guide > > for the logs? > > > > Thanks for any help you can give, > > > > Thomas > > > _______________________________________________ > > FreeIPA-users mailing list -- > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > Fedora Code of Conduct: > https://getfedora.org/code-of-conduct.html > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ >
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET IPA CA CT,C,C
I.domain.NET IPA CA is out of date for those.
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET http://I.domain.NET IPA CA cert. By setting the clock back I managed to get those to renew, now it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET http://I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET http://I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar file used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <flo@redhat.com mailto:flo@redhat.com> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > After some fiddling with dates some more I seem to have the HTTPD cert > in sync, however it appears the cert signing cert is expired. > > named also says it's starting, but doesn't seem to want to respond. > > I don't have time to dig into it more tonight, but let me know what > other information or tests I can run and I'll get them posted tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <xrs444@xrs444.net <mailto:xrs444@xrs444.net> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>> wrote: > > Hello, > > I think this is everything (domain name changed to protect the > guilty!): > > https://pastebin.com/bF1KR7VJ > Hi Thomas, in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format' can be easily explained: there is a typo in the directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you clarify > which > certificate this is? Please provide the subject name, certificate > nickname and location. > > Flo > > I pulled the same on the replica, which appears to be playing > up too > > in a similar fashion. > > > > I did just notice the date on the replica is out, I never set it > > back when I was trying to get the cert to renew. > > > > Let me know if you need anything else. > > > > Thanks, > > > > Thomas > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> wrote: > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via > > FreeIPA-users wrote: > > > Hello all, > > > I had an issue a short while ago with a replica which > turned > > out to be an > > > expired certificate which I renewed and all seemed good. > > > > > > Seemed... > > > > > > It now appears that although the certificate renewed as > seen > > by getcert > > > -list, it didn't update /etc/httpd/alias and so the > httpd and > > tomcat-pki > > > services won't start unless I set the date to before the > > certificate > > > expired, and even then sometimes the httpd error_log shows: > > > Unable to verify certificate 'Server-Cert'. Add > > "NSSEnforceValidCerts off" > > > to nss.conf so the server can start until the problem > can be > > resolved. > > > and the service fails to start. > > > > > Hi Thomas, > > > > Can you please show `getcert list` output on the server in > question, > > as well as the output of > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > and > > > > certutil -d /etc/pki/pki-tomcatd/alias -L <nickname> > > > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > > > And Certmonger journal output. And pki debug log > > /var/log/pki/pki-tomcat/ca/debug. > > > > It is strange that `getcert list' shows an up to date > certificate > > while the actual certificate that is being tracked is > expired... > > > > Thanks, > > Fraser > > > > > I've tried resubmitting the certificate, and it doesn't > seem > > to throw an > > > error, but it doesn't update /alias either. > > > Trying to access the server via the web page shows the old > > certificate > > > still in use. > > > I see the same certificate error with the replica server, > > which was freshly > > > rebuilt and added last week. > > > I've doubtless dug further into the hole trying to > > troubleshoot this, so I > > > probably need to start from the beginning again, and a > > pointer in the right > > > direction would be a great help! > > > > > > A getcert list shows all the certificates expiry dates well > > into the future. > > > > > > How can I get the certs back in sync? I've found a few > guides > > and most seem > > > to be for earlier versions, and I'm not sure if they're > still > > current. > > > > > > I can post whatever logs you think will help, I'm > afraid I'm > > not familiar > > > enough with them all to tell which are the most > relevant. Is > > there a guide > > > for the logs? > > > > > > Thanks for any help you can give, > > > > > > Thomas > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- > > freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > Fedora Code of Conduct: > > https://getfedora.org/code-of-conduct.html > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ > > > > > > > > _______________________________________________ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ > > > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ >
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET IPA CA CT,C,C
I.domain.NET IPA CA is out of date for those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET http://I.domain.NET IPA CA cert. By setting the clock back I managed to get those to renew, now it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET http://I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET http://I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar file used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <flo@redhat.com mailto:flo@redhat.com> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > After some fiddling with dates some more I seem to have the HTTPD cert > in sync, however it appears the cert signing cert is expired. > > named also says it's starting, but doesn't seem to want to respond. > > I don't have time to dig into it more tonight, but let me know what > other information or tests I can run and I'll get them posted tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <xrs444@xrs444.net <mailto:xrs444@xrs444.net> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>> wrote: > > Hello, > > I think this is everything (domain name changed to protect the > guilty!): > > https://pastebin.com/bF1KR7VJ > Hi Thomas, in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format' can be easily explained: there is a typo in the directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you clarify > which > certificate this is? Please provide the subject name, certificate > nickname and location. > > Flo > > I pulled the same on the replica, which appears to be playing > up too > > in a similar fashion. > > > > I did just notice the date on the replica is out, I never set it > > back when I was trying to get the cert to renew. > > > > Let me know if you need anything else. > > > > Thanks, > > > > Thomas > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> wrote: > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas Letherby via > > FreeIPA-users wrote: > > > Hello all, > > > I had an issue a short while ago with a replica which > turned > > out to be an > > > expired certificate which I renewed and all seemed good. > > > > > > Seemed... > > > > > > It now appears that although the certificate renewed as > seen > > by getcert > > > -list, it didn't update /etc/httpd/alias and so the > httpd and > > tomcat-pki > > > services won't start unless I set the date to before the > > certificate > > > expired, and even then sometimes the httpd error_log shows: > > > Unable to verify certificate 'Server-Cert'. Add > > "NSSEnforceValidCerts off" > > > to nss.conf so the server can start until the problem > can be > > resolved. > > > and the service fails to start. > > > > > Hi Thomas, > > > > Can you please show `getcert list` output on the server in > question, > > as well as the output of > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > and > > > > certutil -d /etc/pki/pki-tomcatd/alias -L <nickname> > > > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > > > And Certmonger journal output. And pki debug log > > /var/log/pki/pki-tomcat/ca/debug. > > > > It is strange that `getcert list' shows an up to date > certificate > > while the actual certificate that is being tracked is > expired... > > > > Thanks, > > Fraser > > > > > I've tried resubmitting the certificate, and it doesn't > seem > > to throw an > > > error, but it doesn't update /alias either. > > > Trying to access the server via the web page shows the old > > certificate > > > still in use. > > > I see the same certificate error with the replica server, > > which was freshly > > > rebuilt and added last week. > > > I've doubtless dug further into the hole trying to > > troubleshoot this, so I > > > probably need to start from the beginning again, and a > > pointer in the right > > > direction would be a great help! > > > > > > A getcert list shows all the certificates expiry dates well > > into the future. > > > > > > How can I get the certs back in sync? I've found a few > guides > > and most seem > > > to be for earlier versions, and I'm not sure if they're > still > > current. > > > > > > I can post whatever logs you think will help, I'm > afraid I'm > > not familiar > > > enough with them all to tell which are the most > relevant. Is > > there a guide > > > for the logs? > > > > > > Thanks for any help you can give, > > > > > > Thomas > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- > > freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > Fedora Code of Conduct: > > https://getfedora.org/code-of-conduct.html > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ > > > > > > > > _______________________________________________ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ > > > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ >
Hello Fraser,
The serial numbers appear to match, but if I run ipa-certupdate I get the following:
ipa-certupdate trying https://server1.i.domain.net/ipa/json Connection to https://server1.i.domain.net/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
Tomcat is the only service that appears to be failing with the following error:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8181) Peer's Certificate has expired. (-1)
But it should now be valid as I set the date back. If I set the date to today I get this error:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
Looks like it can't load because the certificate it uses isn't valid, if I roll the clock back so the CA cert is, the certificate Tomcat is using isn't valid and if I roll forward the CA cert isn't.
How can I break this catch 22?
Thanks,
Thomas
On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET IPA CA CT,C,C
I.domain.NET IPA CA is out of date for those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
-a
Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden rcritten@redhat.com
wrote:
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET http://I.domain.NET
IPA
CA cert. By setting the clock back I managed to get those to renew,
now
it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca
CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET http://I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET http://I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar
file
used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
flo@redhat.com
mailto:flo@redhat.com> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > After some fiddling with dates some more I seem to have the
HTTPD
cert > in sync, however it appears the cert signing cert is expired. > > named also says it's starting, but doesn't seem to want to
respond.
> > I don't have time to dig into it more tonight, but let me know
what
> other information or tests I can run and I'll get them posted tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
xrs444@xrs444.net
<mailto:xrs444@xrs444.net> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>> wrote: > > Hello, > > I think this is everything (domain name changed to protect
the
> guilty!): > > https://pastebin.com/bF1KR7VJ > Hi Thomas, in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an
old,
unsupported format' can be easily explained: there is a typo in
the
directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you
clarify
which certificate this is? Please provide the subject name, certificate nickname and location. Flo > I pulled the same on the replica, which appears to be
playing
up too > in a similar fashion. > > I did just notice the date on the replica is out, I never
set
it
> back when I was trying to get the cert to renew. > > Let me know if you need anything else. > > Thanks, > > Thomas > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com> > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
> > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas
Letherby
via
> FreeIPA-users wrote: > > Hello all, > > I had an issue a short while ago with a replica
which
turned > out to be an > > expired certificate which I renewed and all seemed
good.
> > > > Seemed... > > > > It now appears that although the certificate
renewed as
seen > by getcert > > -list, it didn't update /etc/httpd/alias and so the httpd and > tomcat-pki > > services won't start unless I set the date to
before the
> certificate > > expired, and even then sometimes the httpd error_log
shows:
> > Unable to verify certificate 'Server-Cert'. Add > "NSSEnforceValidCerts off" > > to nss.conf so the server can start until the
problem
can be > resolved. > > and the service fails to start. > > > Hi Thomas, > > Can you please show `getcert list` output on the
server in
question, > as well as the output of > > certutil -d /etc/httpd/alias -L Server-Cert > > and > > certutil -d /etc/pki/pki-tomcatd/alias -L
<nickname> > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > > > > > > > And Certmonger journal output. And pki debug log > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > It is strange that `getcert list' shows an up to date > > > certificate > > > > while the actual certificate that is being tracked is > > > expired... > > > > > > > > Thanks, > > > > Fraser > > > > > > > > > I've tried resubmitting the certificate, and it doesn't > > > seem > > > > to throw an > > > > > error, but it doesn't update /alias either. > > > > > Trying to access the server via the web page shows the > > old > > > > certificate > > > > > still in use. > > > > > I see the same certificate error with the replica > > server, > > > > which was freshly > > > > > rebuilt and added last week. > > > > > I've doubtless dug further into the hole trying to > > > > troubleshoot this, so I > > > > > probably need to start from the beginning again, and a > > > > pointer in the right > > > > > direction would be a great help! > > > > > > > > > > A getcert list shows all the certificates expiry dates > > well > > > > into the future. > > > > > > > > > > How can I get the certs back in sync? I've found a few > > > guides > > > > and most seem > > > > > to be for earlier versions, and I'm not sure if they're > > > still > > > > current. > > > > > > > > > > I can post whatever logs you think will help, I'm > > > afraid I'm > > > > not familiar > > > > > enough with them all to tell which are the most > > > relevant. Is > > > > there a guide > > > > > for the logs? > > > > > > > > > > Thanks for any help you can give, > > > > > > > > > > Thomas > > > > > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- > > > > freeipa-users@lists.fedorahosted.org > > > <mailto:freeipa-users@lists.fedorahosted.org> > > > > <mailto:freeipa-users@lists.fedorahosted.org > > > <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave@lists.fedorahosted.org > > > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > > > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > Fedora Code of Conduct: > > > > https://getfedora.org/code-of-conduct.html > > > > > List Guidelines: > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > > <mailto:freeipa-users@lists.fedorahosted.org> > > > > To unsubscribe send an email to > > > freeipa-users-leave@lists.fedorahosted.org > > > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > > List Guidelines: > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > List Archives: > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ > > > > > > > > > > > > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ > > > > > > >
On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote:
Hello Fraser,
The serial numbers appear to match, but if I run ipa-certupdate I get the following:
ipa-certupdate trying https://server1.i.domain.net/ipa/json Connection to https://server1.i.domain.net/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
Tomcat is the only service that appears to be failing with the following error:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8181) Peer's Certificate has expired. (-1)
But it should now be valid as I set the date back. If I set the date to today I get this error:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
Looks like it can't load because the certificate it uses isn't valid, if I roll the clock back so the CA cert is, the certificate Tomcat is using isn't valid and if I roll forward the CA cert isn't.
How can I break this catch 22?
Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate?
In either case, you can look in the Dogtag certificate repository (ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER certificate data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using
certutil -d <nssdb-path> -A -i <cert-path>
If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry to match the "current" certificate.
HTH, Fraser
Thanks,
Thomas
On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET IPA CA CT,C,C
I.domain.NET IPA CA is out of date for those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
-a
Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden rcritten@redhat.com
wrote:
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET http://I.domain.NET
IPA
CA cert. By setting the clock back I managed to get those to renew,
now
it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca
CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET http://I.XRS444.NET IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET http://I.XRS444.NET IPA CA and Signing-Cert are the expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar
file
used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
flo@redhat.com
mailto:flo@redhat.com> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > After some fiddling with dates some more I seem to have the
HTTPD
cert > in sync, however it appears the cert signing cert is expired. > > named also says it's starting, but doesn't seem to want to
respond.
> > I don't have time to dig into it more tonight, but let me know
what
> other information or tests I can run and I'll get them posted tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
xrs444@xrs444.net
<mailto:xrs444@xrs444.net> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>> wrote: > > Hello, > > I think this is everything (domain name changed to protect
the
> guilty!): > > https://pastebin.com/bF1KR7VJ > Hi Thomas, in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an
old,
unsupported format' can be easily explained: there is a typo in
the
directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you
clarify
which certificate this is? Please provide the subject name, certificate nickname and location. Flo > I pulled the same on the replica, which appears to be
playing
up too > in a similar fashion. > > I did just notice the date on the replica is out, I never
set
it
> back when I was trying to get the cert to renew. > > Let me know if you need anything else. > > Thanks, > > Thomas > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com> > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
> > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas
Letherby
via
> FreeIPA-users wrote: > > Hello all, > > I had an issue a short while ago with a replica
which
turned > out to be an > > expired certificate which I renewed and all seemed
good.
> > > > Seemed... > > > > It now appears that although the certificate
renewed as
seen > by getcert > > -list, it didn't update /etc/httpd/alias and so the httpd and > tomcat-pki > > services won't start unless I set the date to
before the
> certificate > > expired, and even then sometimes the httpd error_log
shows:
> > Unable to verify certificate 'Server-Cert'. Add > "NSSEnforceValidCerts off" > > to nss.conf so the server can start until the
problem
can be > resolved. > > and the service fails to start. > > > Hi Thomas, > > Can you please show `getcert list` output on the
server in
question, > as well as the output of > > certutil -d /etc/httpd/alias -L Server-Cert > > and > > certutil -d /etc/pki/pki-tomcatd/alias -L
<nickname> > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > > > > > > > And Certmonger journal output. And pki debug log > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > It is strange that `getcert list' shows an up to date > > > certificate > > > > while the actual certificate that is being tracked is > > > expired... > > > > > > > > Thanks, > > > > Fraser > > > > > > > > > I've tried resubmitting the certificate, and it doesn't > > > seem > > > > to throw an > > > > > error, but it doesn't update /alias either. > > > > > Trying to access the server via the web page shows the > > old > > > > certificate > > > > > still in use. > > > > > I see the same certificate error with the replica > > server, > > > > which was freshly > > > > > rebuilt and added last week. > > > > > I've doubtless dug further into the hole trying to > > > > troubleshoot this, so I > > > > > probably need to start from the beginning again, and a > > > > pointer in the right > > > > > direction would be a great help! > > > > > > > > > > A getcert list shows all the certificates expiry dates > > well > > > > into the future. > > > > > > > > > > How can I get the certs back in sync? I've found a few > > > guides > > > > and most seem > > > > > to be for earlier versions, and I'm not sure if they're > > > still > > > > current. > > > > > > > > > > I can post whatever logs you think will help, I'm > > > afraid I'm > > > > not familiar > > > > > enough with them all to tell which are the most > > > relevant. Is > > > > there a guide > > > > > for the logs? > > > > > > > > > > Thanks for any help you can give, > > > > > > > > > > Thomas > > > > > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- > > > > freeipa-users@lists.fedorahosted.org > > > <mailto:freeipa-users@lists.fedorahosted.org> > > > > <mailto:freeipa-users@lists.fedorahosted.org > > > <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave@lists.fedorahosted.org > > > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org > > > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > Fedora Code of Conduct: > > > > https://getfedora.org/code-of-conduct.html > > > > > List Guidelines: > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > > <mailto:freeipa-users@lists.fedorahosted.org> > > > > To unsubscribe send an email to > > > freeipa-users-leave@lists.fedorahosted.org > > > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > > List Guidelines: > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > List Archives: > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ > > > > > > > > > > > > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ > > > > > > >
Hello Fraser,
As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired:
certutil -d /etc/pki/pki-tomcat/alias -L Up to date
certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET IPA CA
certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET IPA CA
getcert-list all up to date.
ipa-getcert list all up to date
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date
I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours?
Thomas
On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote:
Hello Fraser,
The serial numbers appear to match, but if I run ipa-certupdate I get the following:
ipa-certupdate trying https://server1.i.domain.net/ipa/json Connection to https://server1.i.domain.net/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
Tomcat is the only service that appears to be failing with the following error:
Internal Database Error encountered: Could not connect to LDAP server
host
xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-8181)
Peer's Certificate has expired. (-1)
But it should now be valid as I set the date back. If I set the date to today I get this error:
Internal Database Error encountered: Could not connect to LDAP server
host
xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-12195)
Peer does not recognize and trust the CA that issued your certificate.
(-1)
Looks like it can't load because the certificate it uses isn't valid, if
I
roll the clock back so the CA cert is, the certificate Tomcat is using isn't valid and if I roll forward the CA cert isn't.
How can I break this catch 22?
Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate?
In either case, you can look in the Dogtag certificate repository (ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER certificate data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using
certutil -d <nssdb-path> -A -i <cert-path>
If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry to match the "current" certificate.
HTH, Fraser
Thanks,
Thomas
On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET IPA CA CT,C,C
I.domain.NET IPA CA is out of date for those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca'
-a
Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden rcritten@redhat.com
wrote:
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET <
IPA
CA cert. By setting the clock back I managed to get those to
renew,
now
it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP
server
host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636
Error
netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake
failed:
(-12195) Peer does not recognize and trust the CA that issued
your
certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname
Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca
u,u,u
ocspSigningCert cert-pki-ca
u,u,u
O=domain,ST=Arizona,C=US
CT,C,C
auditSigningCert cert-pki-ca
u,u,Pu
subsystemCert cert-pki-ca
u,u,u
caSigningCert cert-pki-ca
CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname
Trust
Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert
u,u,u
O=xrs444,ST=Arizona,C=US
CT,C,C
I.XRS444.NET http://I.XRS444.NET IPA CA CT,C,C Server-Cert
u,u,u
I.XRS444.NET http://I.XRS444.NET IPA CA and Signing-Cert are
the
expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar
file
used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
flo@redhat.com
mailto:flo@redhat.com> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users
wrote:
> After some fiddling with dates some more I seem to have the
HTTPD
cert > in sync, however it appears the cert signing cert is
expired.
> > named also says it's starting, but doesn't seem to want to
respond.
> > I don't have time to dig into it more tonight, but let me
know
what
> other information or tests I can run and I'll get them
posted
tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
xrs444@xrs444.net
<mailto:xrs444@xrs444.net> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>
wrote:
> > Hello, > > I think this is everything (domain name changed to
protect
the
> guilty!): > > https://pastebin.com/bF1KR7VJ > Hi Thomas, in the provided pastebin, the error 'certutil: function
failed:
SEC_ERROR_LEGACY_DATABASE: The certificate/key database is
in an
old,
unsupported format' can be easily explained: there is a typo
in
the
directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you
clarify
which certificate this is? Please provide the subject name,
certificate
nickname and location. Flo > I pulled the same on the replica, which appears to be
playing
up too > in a similar fashion. > > I did just notice the date on the replica is out, I
never
set
it
> back when I was trying to get the cert to renew. > > Let me know if you need anything else. > > Thanks, > > Thomas > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com> > <mailto:ftweedal@redhat.com <mailto:
ftweedal@redhat.com>>>
wrote:
> > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas
Letherby
via
> FreeIPA-users wrote: > > Hello all, > > I had an issue a short while ago with a replica
which
turned > out to be an > > expired certificate which I renewed and all
seemed
good.
> > > > Seemed... > > > > It now appears that although the certificate
renewed as
seen > by getcert > > -list, it didn't update /etc/httpd/alias and so
the
httpd and > tomcat-pki > > services won't start unless I set the date to
before the
> certificate > > expired, and even then sometimes the httpd
error_log
shows:
> > Unable to verify certificate 'Server-Cert'. Add > "NSSEnforceValidCerts off" > > to nss.conf so the server can start until the
problem
can be > resolved. > > and the service fails to start. > > > Hi Thomas, > > Can you please show `getcert list` output on the
server in
question, > as well as the output of > > certutil -d /etc/httpd/alias -L Server-Cert > > and > > certutil -d /etc/pki/pki-tomcatd/alias -L
<nickname> > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > > > > > > > And Certmonger journal output. And pki debug log > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > It is strange that `getcert list' shows an up to
date
certificate > while the actual certificate that is being tracked
is
expired... > > Thanks, > Fraser > > > I've tried resubmitting the certificate, and it
doesn't
seem > to throw an > > error, but it doesn't update /alias either. > > Trying to access the server via the web page
shows
the
old
> certificate > > still in use. > > I see the same certificate error with the
replica
server,
> which was freshly > > rebuilt and added last week. > > I've doubtless dug further into the hole trying
to
> troubleshoot this, so I > > probably need to start from the beginning again,
and a
> pointer in the right > > direction would be a great help! > > > > A getcert list shows all the certificates expiry
dates
well
> into the future. > > > > How can I get the certs back in sync? I've
found a
few
guides > and most seem > > to be for earlier versions, and I'm not sure if
they're
still > current. > > > > I can post whatever logs you think will help,
I'm
afraid I'm > not familiar > > enough with them all to tell which are the most relevant. Is > there a guide > > for the logs? > > > > Thanks for any help you can give, > > > > Thomas > > > _______________________________________________ > > FreeIPA-users mailing list -- > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > Fedora Code of Conduct: > https://getfedora.org/code-of-conduct.html > > List Guidelines: >
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > _______________________________________________ > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
From that I know you could trigger a refresh by restarting certmonger.
On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hello Fraser,
As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired:
certutil -d /etc/pki/pki-tomcat/alias -L Up to date
certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET http://i.domain.net/ IPA CA
certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET http://i.domain.net/ IPA CA
getcert-list all up to date.
ipa-getcert list all up to date
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET http://i.domain.net/ IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date
I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours?
Thomas
On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale <ftweedal@redhat.com mailto:ftweedal@redhat.com> wrote: On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote:
Hello Fraser,
The serial numbers appear to match, but if I run ipa-certupdate I get the following:
ipa-certupdate trying https://server1.i.domain.net/ipa/json https://server1.i.domain.net/ipa/json Connection to https://server1.i.domain.net/ipa/json https://server1.i.domain.net/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
Tomcat is the only service that appears to be failing with the following error:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net/ port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8181) Peer's Certificate has expired. (-1)
But it should now be valid as I set the date back. If I set the date to today I get this error:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net/ port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
Looks like it can't load because the certificate it uses isn't valid, if I roll the clock back so the CA cert is, the certificate Tomcat is using isn't valid and if I roll forward the CA cert isn't.
How can I break this catch 22?
Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate?
In either case, you can look in the Dogtag certificate repository (ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER certificate data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using
certutil -d <nssdb-path> -A -i <cert-path>
If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry to match the "current" certificate.
HTH, Fraser
Thanks,
Thomas
On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale <ftweedal@redhat.com mailto:ftweedal@redhat.com> wrote:
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET http://i.domain.net/ IPA CA CT,C,C
I.domain.NET http://i.domain.net/ IPA CA is out of date for those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
-a
Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden <rcritten@redhat.com mailto:rcritten@redhat.com>
wrote:
Thomas Letherby via FreeIPA-users wrote:
Hello Florence,
It was the Signing-Cert and the I.domain.NET http://i.domain.net/ <http://I.domain.NET http://i.domain.net/>
IPA
CA cert. By setting the clock back I managed to get those to renew,
now
it seems I just need to get tomcat-pki to start.
The error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.xrs444.net http://xipa1.i.xrs444.net/ <http://xipa1.i.xrs444.net http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) Peer does not recognize and trust the CA that issued your certificate. (-1)
certutil -d /etc/pki/pki-tomcat/alias -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u O=domain,ST=Arizona,C=US CT,C,C auditSigningCert cert-pki-ca u,u,Pu subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca
CTu,Cu,Cu
These are all set to expire in 2020 or beyond.
certutil -d /etc/httpd/alias -L Server-Cert
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Signing-Cert u,u,u O=xrs444,ST=Arizona,C=US CT,C,C I.XRS444.NET http://i.xrs444.net/ <http://I.XRS444.NET http://i.xrs444.net/> IPA CA CT,C,C Server-Cert u,u,u
I.XRS444.NET http://i.xrs444.net/ <http://I.XRS444.NET http://i.xrs444.net/> IPA CA and Signing-Cert are the expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the jar
file
used to autoconfigure Firefox. You should never need to re-sign one again (and this method isn't allowed in modern Firefox anyway).
rob
Thomas
On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
flo@redhat.com mailto:flo@redhat.com
<mailto:flo@redhat.com mailto:flo@redhat.com>> wrote:
On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > After some fiddling with dates some more I seem to have the
HTTPD
cert > in sync, however it appears the cert signing cert is expired. > > named also says it's starting, but doesn't seem to want to
respond.
> > I don't have time to dig into it more tonight, but let me know
what
> other information or tests I can run and I'll get them posted tomorrow. > > Thanks all. > > Thomas > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
xrs444@xrs444.net mailto:xrs444@xrs444.net
<mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>> wrote: > > Hello, > > I think this is everything (domain name changed to protect
the
> guilty!): > > https://pastebin.com/bF1KR7VJ <https://pastebin.com/bF1KR7VJ> > Hi Thomas, in the provided pastebin, the error 'certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an
old,
unsupported format' can be easily explained: there is a typo in
the
directory path. You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you
clarify
which certificate this is? Please provide the subject name, certificate nickname and location. Flo > I pulled the same on the replica, which appears to be
playing
up too > in a similar fashion. > > I did just notice the date on the replica is out, I never
set
it
> back when I was trying to get the cert to renew. > > Let me know if you need anything else. > > Thanks, > > Thomas > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>
wrote:
> > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas
Letherby
via
> FreeIPA-users wrote: > > Hello all, > > I had an issue a short while ago with a replica
which
turned > out to be an > > expired certificate which I renewed and all seemed
good.
> > > > Seemed... > > > > It now appears that although the certificate
renewed as
seen > by getcert > > -list, it didn't update /etc/httpd/alias and so the httpd and > tomcat-pki > > services won't start unless I set the date to
before the
> certificate > > expired, and even then sometimes the httpd error_log
shows:
> > Unable to verify certificate 'Server-Cert'. Add > "NSSEnforceValidCerts off" > > to nss.conf so the server can start until the
problem
can be > resolved. > > and the service fails to start. > > > Hi Thomas, > > Can you please show `getcert list` output on the
server in
question, > as well as the output of > > certutil -d /etc/httpd/alias -L Server-Cert > > and > > certutil -d /etc/pki/pki-tomcatd/alias -L
<nickname> > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias NSSDB. > > > > > > > > And Certmonger journal output. And pki debug log > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > It is strange that `getcert list' shows an up to date > > > certificate > > > > while the actual certificate that is being tracked is > > > expired... > > > > > > > > Thanks, > > > > Fraser > > > > > > > > > I've tried resubmitting the certificate, and it doesn't > > > seem > > > > to throw an > > > > > error, but it doesn't update /alias either. > > > > > Trying to access the server via the web page shows the > > old > > > > certificate > > > > > still in use. > > > > > I see the same certificate error with the replica > > server, > > > > which was freshly > > > > > rebuilt and added last week. > > > > > I've doubtless dug further into the hole trying to > > > > troubleshoot this, so I > > > > > probably need to start from the beginning again, and a > > > > pointer in the right > > > > > direction would be a great help! > > > > > > > > > > A getcert list shows all the certificates expiry dates > > well > > > > into the future. > > > > > > > > > > How can I get the certs back in sync? I've found a few > > > guides > > > > and most seem > > > > > to be for earlier versions, and I'm not sure if they're > > > still > > > > current. > > > > > > > > > > I can post whatever logs you think will help, I'm > > > afraid I'm > > > > not familiar > > > > > enough with them all to tell which are the most > > > relevant. Is > > > > there a guide > > > > > for the logs? > > > > > > > > > > Thanks for any help you can give, > > > > > > > > > > Thomas > > > > > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> > > > > > Fedora Code of Conduct: > > > > https://getfedora.org/code-of-conduct.html <https://getfedora.org/code-of-conduct.html> > > > > > List Guidelines: > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> > > > > > List Archives: > > > > > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ <https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/> > > > > > > > > > > > > > > > > _______________________________________________ > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > To unsubscribe send an email to > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html <https://getfedora.org/code-of-conduct.html> > > > > List Guidelines: > > > https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> > > > > List Archives: > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ <https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/> > > > > > > > > > > > > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html <https://getfedora.org/code-of-conduct.html> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> > > > List Archives: > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ <https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/> > > > > > > >
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost... https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Z2CWAOM4HBHXWBCQRFJXFCHMOEBRFPPO/
Well, after poking around with the dates and a few restarts of services, IPA now starts seemingly cleanly at the current date, although the clients still don't seem to want to trust the CA, and I'm still seeing the old cert crop up.
If I look at the cert that wasn't updating before, it now seems to contain three certs, the expired one and two new with much longer expiry dates.
[root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n " I.DOMAIN.NET IPA CA" | grep Not Not Before: Sun Jun 17 09:06:38 2018 Not After : Thu Jun 17 09:06:38 2038 Not Before: Sun Jun 17 07:24:26 2018 Not After : Thu Jun 17 07:24:26 2038 Not Before: Thu Jun 08 06:51:04 2017 Not After : Mon Jun 18 06:51:04 2018
Is this correct, or has it not updated the certificate correctly, if so, how do I clean it up?
Thanks,
Thomas
On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS christophe.trefois@uni.lu wrote:
From that I know you could trigger a refresh by restarting certmonger.
On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello Fraser,
As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired:
certutil -d /etc/pki/pki-tomcat/alias -L Up to date
certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET http://i.domain.net/ IPA CA
certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET http://i.domain.net/ IPA CA
getcert-list all up to date.
ipa-getcert list all up to date
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET http://i.domain.net/ IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date
I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours?
Thomas
On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote:
Hello Fraser,
The serial numbers appear to match, but if I run ipa-certupdate I get
the
following:
ipa-certupdate trying https://server1.i.domain.net/ipa/json Connection to https://server1.i.domain.net/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
Tomcat is the only service that appears to be failing with the following error:
Internal Database Error encountered: Could not connect to LDAP server
host
xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable
to
create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-8181)
Peer's Certificate has expired. (-1)
But it should now be valid as I set the date back. If I set the date to today I get this error:
Internal Database Error encountered: Could not connect to LDAP server
host
xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable
to
create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-12195)
Peer does not recognize and trust the CA that issued your certificate.
(-1)
Looks like it can't load because the certificate it uses isn't valid,
if I
roll the clock back so the CA cert is, the certificate Tomcat is using isn't valid and if I roll forward the CA cert isn't.
How can I break this catch 22?
Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate?
In either case, you can look in the Dogtag certificate repository (ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER certificate data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using
certutil -d <nssdb-path> -A -i <cert-path>
If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry to match the "current" certificate.
HTH, Fraser
Thanks,
Thomas
On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET http://i.domain.net/ IPA CA
CT,C,C
I.domain.NET http://i.domain.net/ IPA CA is out of date for
those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca'
-a
Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden <rcritten@redhat.com
wrote:
Thomas Letherby via FreeIPA-users wrote: > Hello Florence, > > It was the Signing-Cert and the I.domain.NET
http://i.domain.net/ <http://I.domain.NET http://i.domain.net/>
IPA
> CA cert. By setting the clock back I managed to get those to
renew,
now
> it seems I just need to get tomcat-pki to start. > > The error is: > > Internal Database Error encountered: Could not connect to LDAP
server
> host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636
Error
> netscape.ldap.LDAPException: Unable to create socket: > org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake
failed:
> (-12195) Peer does not recognize and trust the CA that issued
your
> certificate. (-1) > > certutil -d /etc/pki/pki-tomcat/alias -L > > Certificate Nickname
Trust
> Attributes > > SSL,S/MIME,JAR/XPI > > Server-Cert cert-pki-ca
u,u,u
> ocspSigningCert cert-pki-ca
u,u,u
> O=domain,ST=Arizona,C=US
CT,C,C
> auditSigningCert cert-pki-ca
u,u,Pu
> subsystemCert cert-pki-ca
u,u,u
> caSigningCert cert-pki-ca
CTu,Cu,Cu
> > These are all set to expire in 2020 or beyond. > > certutil -d /etc/httpd/alias -L Server-Cert > > Certificate Nickname
Trust
> Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert
u,u,u
> O=xrs444,ST=Arizona,C=US
CT,C,C
> I.XRS444.NET http://i.xrs444.net/ <http://I.XRS444.NET
http://i.xrs444.net/> IPA CA
> CT,C,C > Server-Cert
u,u,u
> > I.XRS444.NET http://i.xrs444.net/ <http://I.XRS444.NET
http://i.xrs444.net/> IPA CA and Signing-Cert are the
> expired certs here.
Don't worry about Signing-Cert. It is the cert used to sign the
jar
file
used to autoconfigure Firefox. You should never need to re-sign
one
again (and this method isn't allowed in modern Firefox anyway).
rob
> > Thomas > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
flo@redhat.com
> mailto:flo@redhat.com> wrote: > > On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users
wrote:
> > After some fiddling with dates some more I seem to have
the
HTTPD
> cert > > in sync, however it appears the cert signing cert is
expired.
> > > > named also says it's starting, but doesn't seem to want to
respond.
> > > > I don't have time to dig into it more tonight, but let me
know
what
> > other information or tests I can run and I'll get them
posted
> tomorrow. > > > > Thanks all. > > > > Thomas > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
xrs444@xrs444.net
> mailto:xrs444@xrs444.net > > <mailto:xrs444@xrs444.net mailto:xrs444@xrs444.net>>
wrote:
> > > > Hello, > > > > I think this is everything (domain name changed to
protect
the
> > guilty!): > > > > https://pastebin.com/bF1KR7VJ > > > Hi Thomas, > > in the provided pastebin, the error 'certutil: function
failed:
> SEC_ERROR_LEGACY_DATABASE: The certificate/key database is
in an
old,
> unsupported format' can be easily explained: there is a
typo in
the
> directory path. > You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n
<nickname> > (note the pki-tomcat instead of pki-tomcat*d*). > > You mention that the cert signing cert is expired, can you
clarify
> which > certificate this is? Please provide the subject name,
certificate
> nickname and location. > > Flo > > I pulled the same on the replica, which appears to be
playing
> up too > > in a similar fashion. > > > > I did just notice the date on the replica is out, I
never
set
it > > back when I was trying to get the cert to renew. > > > > Let me know if you need anything else. > > > > Thanks, > > > > Thomas > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > <ftweedal@redhat.com mailto:ftweedal@redhat.com > > <mailto:ftweedal@redhat.com <mailto:
ftweedal@redhat.com>>>
wrote: > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas
Letherby
via > > FreeIPA-users wrote: > > > Hello all, > > > I had an issue a short while ago with a replica
which
> turned > > out to be an > > > expired certificate which I renewed and all
seemed
good.
> > > > > > Seemed... > > > > > > It now appears that although the certificate
renewed as
> seen > > by getcert > > > -list, it didn't update /etc/httpd/alias and
so the
> httpd and > > tomcat-pki > > > services won't start unless I set the date to
before the
> > certificate > > > expired, and even then sometimes the httpd
error_log
shows: > > > Unable to verify certificate 'Server-Cert'. Add > > "NSSEnforceValidCerts off" > > > to nss.conf so the server can start until the
problem
> can be > > resolved. > > > and the service fails to start. > > > > > Hi Thomas, > > > > Can you please show `getcert list` output on the
server in
> question, > > as well as the output of > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > and > > > > certutil -d /etc/pki/pki-tomcatd/alias -L
<nickname> > > > > > > > > for each nickname in the
/etc/pki/pki-tomcatd/alias
NSSDB.
> > > > And Certmonger journal output. And pki debug log > > /var/log/pki/pki-tomcat/ca/debug. > > > > It is strange that `getcert list' shows an up to
date
> certificate > > while the actual certificate that is being
tracked is
> expired... > > > > Thanks, > > Fraser > > > > > I've tried resubmitting the certificate, and it
doesn't
> seem > > to throw an > > > error, but it doesn't update /alias either. > > > Trying to access the server via the web page
shows
the
old > > certificate > > > still in use. > > > I see the same certificate error with the
replica
server, > > which was freshly > > > rebuilt and added last week. > > > I've doubtless dug further into the hole
trying to
> > troubleshoot this, so I > > > probably need to start from the beginning
again,
and a
> > pointer in the right > > > direction would be a great help! > > > > > > A getcert list shows all the certificates
expiry
dates
well > > into the future. > > > > > > How can I get the certs back in sync? I've
found a
few
> guides > > and most seem > > > to be for earlier versions, and I'm not sure if
they're
> still > > current. > > > > > > I can post whatever logs you think will help,
I'm
> afraid I'm > > not familiar > > > enough with them all to tell which are the most > relevant. Is > > there a guide > > > for the logs? > > > > > > Thanks for any help you can give, > > > > > > Thomas > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- > > freeipa-users@lists.fedorahosted.org > mailto:freeipa-users@lists.fedorahosted.org > > mailto:freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org > mailto:freeipa-users-leave@lists.fedorahosted.org > > <mailto:
freeipa-users-leave@lists.fedorahosted.org
> mailto:freeipa-users-leave@lists.fedorahosted.org> > > > Fedora Code of Conduct: > > https://getfedora.org/code-of-conduct.html > > > List Guidelines: > >
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > _______________________________________________ > > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> mailto:freeipa-users@lists.fedorahosted.org > > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org > mailto:freeipa-users-leave@lists.fedorahosted.org > > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > _______________________________________________ > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Just to add, getcert seems to think they're all up to date:
getcert list | grep expires expires: 2019-06-16 04:38:58 UTC expires: 2020-06-05 01:24:55 UTC expires: 2020-06-05 01:29:28 UTC expires: 2020-06-05 01:32:01 UTC expires: 2038-06-17 09:06:38 UTC expires: 2020-06-05 01:34:31 UTC expires: 2020-06-01 00:43:22 UTC expires: 2020-06-15 04:08:47 UTC expires: 2020-06-16 03:20:19 UTC
ipa-getcert list | grep expires expires: 2020-06-15 04:08:47 UTC expires: 2020-06-16 03:20:19 UTC
Thomas
On Wed, Jul 11, 2018 at 5:33 PM Thomas Letherby xrs444@xrs444.net wrote:
Well, after poking around with the dates and a few restarts of services, IPA now starts seemingly cleanly at the current date, although the clients still don't seem to want to trust the CA, and I'm still seeing the old cert crop up.
If I look at the cert that wasn't updating before, it now seems to contain three certs, the expired one and two new with much longer expiry dates.
[root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n " I.DOMAIN.NET IPA CA" | grep Not Not Before: Sun Jun 17 09:06:38 2018 Not After : Thu Jun 17 09:06:38 2038 Not Before: Sun Jun 17 07:24:26 2018 Not After : Thu Jun 17 07:24:26 2038 Not Before: Thu Jun 08 06:51:04 2017 Not After : Mon Jun 18 06:51:04 2018
Is this correct, or has it not updated the certificate correctly, if so, how do I clean it up?
Thanks,
Thomas
On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS < christophe.trefois@uni.lu> wrote:
From that I know you could trigger a refresh by restarting certmonger.
On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello Fraser,
As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired:
certutil -d /etc/pki/pki-tomcat/alias -L Up to date
certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET http://i.domain.net/ IPA CA
certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET http://i.domain.net/ IPA CA
getcert-list all up to date.
ipa-getcert list all up to date
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET http://i.domain.net/ IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired
ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date
I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours?
Thomas
On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote:
Hello Fraser,
The serial numbers appear to match, but if I run ipa-certupdate I get
the
following:
ipa-certupdate trying https://server1.i.domain.net/ipa/json Connection to https://server1.i.domain.net/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
Tomcat is the only service that appears to be failing with the
following
error:
Internal Database Error encountered: Could not connect to LDAP server
host
xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable
to
create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-8181)
Peer's Certificate has expired. (-1)
But it should now be valid as I set the date back. If I set the date to today I get this error:
Internal Database Error encountered: Could not connect to LDAP server
host
xipa1.i.xrs444.net port 636 Error netscape.ldap.LDAPException: Unable
to
create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-12195)
Peer does not recognize and trust the CA that issued your certificate.
(-1)
Looks like it can't load because the certificate it uses isn't valid,
if I
roll the clock back so the CA cert is, the certificate Tomcat is using isn't valid and if I roll forward the CA cert isn't.
How can I break this catch 22?
Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate?
In either case, you can look in the Dogtag certificate repository (ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER certificate data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using
certutil -d <nssdb-path> -A -i <cert-path>
If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry to match the "current" certificate.
HTH, Fraser
Thanks,
Thomas
On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale ftweedal@redhat.com wrote:
On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote:
Hello all,
Here's the info:
certutil -d /etc/dirsrv/slapd-I-domain-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=domain,ST=Arizona,C=US CT,C,C I.domain.NET http://i.domain.net/ IPA CA
CT,C,C
I.domain.NET http://i.domain.net/ IPA CA is out of date for
those.
Try running ipa-certupdate. It will update the IPA CA certificate in the various trust stores including the DS NSSDB.
It reads the certificates from
cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
so you should probably check that the certificate in that entry is up to date also.
Cheers, Fraser
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca'
-a
Not After : Fri Jun 05 01:32:01 2020 Matches ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
Thomas
On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden <
rcritten@redhat.com>
wrote:
> Thomas Letherby via FreeIPA-users wrote: > > Hello Florence, > > > > It was the Signing-Cert and the I.domain.NET
http://i.domain.net/ <http://I.domain.NET http://i.domain.net/>
IPA
> > CA cert. By setting the clock back I managed to get those to
renew,
now
> > it seems I just need to get tomcat-pki to start. > > > > The error is: > > > > Internal Database Error encountered: Could not connect to LDAP
server
> > host xipa1.i.xrs444.net http://xipa1.i.xrs444.net port 636
Error
> > netscape.ldap.LDAPException: Unable to create socket: > > org.mozilla.jss.ssl.SSLSocketException: > > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake
failed:
> > (-12195) Peer does not recognize and trust the CA that issued
your
> > certificate. (-1) > > > > certutil -d /etc/pki/pki-tomcat/alias -L > > > > Certificate Nickname
Trust
> > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Server-Cert cert-pki-ca
u,u,u
> > ocspSigningCert cert-pki-ca
u,u,u
> > O=domain,ST=Arizona,C=US
CT,C,C
> > auditSigningCert cert-pki-ca
u,u,Pu
> > subsystemCert cert-pki-ca
u,u,u
> > caSigningCert cert-pki-ca
CTu,Cu,Cu
> > > > These are all set to expire in 2020 or beyond. > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > Certificate Nickname
Trust
> > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert
u,u,u
> > O=xrs444,ST=Arizona,C=US
CT,C,C
> > I.XRS444.NET http://i.xrs444.net/ <http://I.XRS444.NET
http://i.xrs444.net/> IPA CA
> > CT,C,C > > Server-Cert
u,u,u
> > > > I.XRS444.NET http://i.xrs444.net/ <http://I.XRS444.NET
http://i.xrs444.net/> IPA CA and Signing-Cert are the
> > expired certs here. > > Don't worry about Signing-Cert. It is the cert used to sign the
jar
file
> used to autoconfigure Firefox. You should never need to re-sign
one
> again (and this method isn't allowed in modern Firefox anyway). > > rob > > > > > Thomas > > > > > > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
flo@redhat.com
> > mailto:flo@redhat.com> wrote: > > > > On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users
wrote:
> > > After some fiddling with dates some more I seem to have
the
HTTPD
> > cert > > > in sync, however it appears the cert signing cert is
expired.
> > > > > > named also says it's starting, but doesn't seem to want
to
respond.
> > > > > > I don't have time to dig into it more tonight, but let
me know
what
> > > other information or tests I can run and I'll get them
posted
> > tomorrow. > > > > > > Thanks all. > > > > > > Thomas > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
xrs444@xrs444.net
> > mailto:xrs444@xrs444.net > > > <mailto:xrs444@xrs444.net mailto:xrs444@xrs444.net>>
wrote:
> > > > > > Hello, > > > > > > I think this is everything (domain name changed to
protect
the
> > > guilty!): > > > > > > https://pastebin.com/bF1KR7VJ > > > > > Hi Thomas, > > > > in the provided pastebin, the error 'certutil: function
failed:
> > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is
in an
old,
> > unsupported format' can be easily explained: there is a
typo in
the
> > directory path. > > You can try with certutil -d /etc/pki/pki-tomcat/alias -L
-n
> <nickname> > > (note the pki-tomcat instead of pki-tomcat*d*). > > > > You mention that the cert signing cert is expired, can you
clarify
> > which > > certificate this is? Please provide the subject name,
certificate
> > nickname and location. > > > > Flo > > > I pulled the same on the replica, which appears to be
playing
> > up too > > > in a similar fashion. > > > > > > I did just notice the date on the replica is out, I
never
set
> it > > > back when I was trying to get the cert to renew. > > > > > > Let me know if you need anything else. > > > > > > Thanks, > > > > > > Thomas > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > > <ftweedal@redhat.com mailto:ftweedal@redhat.com > > > <mailto:ftweedal@redhat.com <mailto:
ftweedal@redhat.com>>>
> wrote: > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas
Letherby
> via > > > FreeIPA-users wrote: > > > > Hello all, > > > > I had an issue a short while ago with a
replica
which
> > turned > > > out to be an > > > > expired certificate which I renewed and all
seemed
good.
> > > > > > > > Seemed... > > > > > > > > It now appears that although the certificate
renewed as
> > seen > > > by getcert > > > > -list, it didn't update /etc/httpd/alias and
so the
> > httpd and > > > tomcat-pki > > > > services won't start unless I set the date to
before the
> > > certificate > > > > expired, and even then sometimes the httpd
error_log
> shows: > > > > Unable to verify certificate 'Server-Cert'.
Add
> > > "NSSEnforceValidCerts off" > > > > to nss.conf so the server can start until the
problem
> > can be > > > resolved. > > > > and the service fails to start. > > > > > > > Hi Thomas, > > > > > > Can you please show `getcert list` output on the
server in
> > question, > > > as well as the output of > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > and > > > > > > certutil -d /etc/pki/pki-tomcatd/alias -L
<nickname> > > > > > > > > for each nickname in the
/etc/pki/pki-tomcatd/alias
NSSDB.
> > > > > > And Certmonger journal output. And pki debug log > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > It is strange that `getcert list' shows an up to
date
> > certificate > > > while the actual certificate that is being
tracked is
> > expired... > > > > > > Thanks, > > > Fraser > > > > > > > I've tried resubmitting the certificate, and
it
doesn't
> > seem > > > to throw an > > > > error, but it doesn't update /alias either. > > > > Trying to access the server via the web page
shows
the
> old > > > certificate > > > > still in use. > > > > I see the same certificate error with the
replica
> server, > > > which was freshly > > > > rebuilt and added last week. > > > > I've doubtless dug further into the hole
trying to
> > > troubleshoot this, so I > > > > probably need to start from the beginning
again,
and a
> > > pointer in the right > > > > direction would be a great help! > > > > > > > > A getcert list shows all the certificates
expiry
dates
> well > > > into the future. > > > > > > > > How can I get the certs back in sync? I've
found a
few
> > guides > > > and most seem > > > > to be for earlier versions, and I'm not sure
if
they're
> > still > > > current. > > > > > > > > I can post whatever logs you think will help,
I'm
> > afraid I'm > > > not familiar > > > > enough with them all to tell which are the
most
> > relevant. Is > > > there a guide > > > > for the logs? > > > > > > > > Thanks for any help you can give, > > > > > > > > Thomas > > > > > > >
> > > > FreeIPA-users mailing list -- > > > freeipa-users@lists.fedorahosted.org > > mailto:freeipa-users@lists.fedorahosted.org > > > mailto:freeipa-users@lists.fedorahosted.org > mailto:freeipa-users@lists.fedorahosted.org> > > > > To unsubscribe send an email to > > > freeipa-users-leave@lists.fedorahosted.org > > mailto:freeipa-users-leave@lists.fedorahosted.org > > > <mailto:
freeipa-users-leave@lists.fedorahosted.org
> > mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > Fedora Code of Conduct: > > > https://getfedora.org/code-of-conduct.html > > > > List Guidelines: > > >
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > _______________________________________________ > > > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> > mailto:freeipa-users@lists.fedorahosted.org > > > To unsubscribe send an email to > > freeipa-users-leave@lists.fedorahosted.org > > mailto:freeipa-users-leave@lists.fedorahosted.org > > > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > _______________________________________________ > > FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org > > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > >
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Thomas Letherby wrote:
Well, after poking around with the dates and a few restarts of services, IPA now starts seemingly cleanly at the current date, although the clients still don't seem to want to trust the CA, and I'm still seeing the old cert crop up.
If I look at the cert that wasn't updating before, it now seems to contain three certs, the expired one and two new with much longer expiry dates.
[root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n "I.DOMAIN.NET http://I.DOMAIN.NET IPA CA" | grep Not Not Before: Sun Jun 17 09:06:38 2018 Not After : Thu Jun 17 09:06:38 2038 Not Before: Sun Jun 17 07:24:26 2018 Not After : Thu Jun 17 07:24:26 2038 Not Before: Thu Jun 08 06:51:04 2017 Not After : Mon Jun 18 06:51:04 2018
Is this correct, or has it not updated the certificate correctly, if so, how do I clean it up?
This is rather confusing output. I think we need to see the full certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point?
rob
Thanks,
Thomas
On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS <christophe.trefois@uni.lu mailto:christophe.trefois@uni.lu> wrote:
From that I know you could trigger a refresh by restarting certmonger.
On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> wrote: Hello Fraser, As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired: certutil -d /etc/pki/pki-tomcat/alias -L Up to date certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET <http://i.domain.net/> IPA CA certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET <http://i.domain.net/> IPA CA getcert-list all up to date. ipa-getcert list all up to date ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://i.domain.net/> IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours? Thomas On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote: On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: > Hello Fraser, > > The serial numbers appear to match, but if I run ipa-certupdate I get the > following: > > ipa-certupdate > trying https://server1.i.domain.net/ipa/json > Connection to https://server1.i.domain.net/ipa/json failed with [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) > > Tomcat is the only service that appears to be failing with the following > error: > > Internal Database Error encountered: Could not connect to LDAP server host > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to > create socket: org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8181) > Peer's Certificate has expired. (-1) > > But it should now be valid as I set the date back. If I set the date to > today I get this error: > > Internal Database Error encountered: Could not connect to LDAP server host > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to > create socket: org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) > Peer does not recognize and trust the CA that issued your certificate. (-1) > > Looks like it can't load because the certificate it uses isn't valid, if I > roll the clock back so the CA cert is, the certificate Tomcat is using > isn't valid and if I roll forward the CA cert isn't. > > How can I break this catch 22? > Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate? In either case, you can look in the Dogtag certificate repository (ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER certificate data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using certutil -d <nssdb-path> -A -i <cert-path> If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry to match the "current" certificate. HTH, Fraser > Thanks, > > Thomas > > > > > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > wrote: > > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote: > > > Hello all, > > > > > > Here's the info: > > > > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L > > > > > > Certificate Nickname Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > > > > Server-Cert u,u,u > > > O=domain,ST=Arizona,C=US CT,C,C > > > I.domain.NET <http://i.domain.net/> IPA CA CT,C,C > > > > > > I.domain.NET <http://i.domain.net/> IPA CA is out of date for those. > > > > > Try running ipa-certupdate. It will update the IPA CA certificate > > in the various trust stores including the DS NSSDB. > > > > It reads the certificates from > > > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} > > > > so you should probably check that the certificate in that entry is > > up to date also. > > > > Cheers, > > Fraser > > > > > certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' > > -a > > > Not After : Fri Jun 05 01:32:01 2020 > > > Matches > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > > > > > > Thomas > > > > > > > > > > > > > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> > > wrote: > > > > > > > Thomas Letherby via FreeIPA-users wrote: > > > > > Hello Florence, > > > > > > > > > > It was the Signing-Cert and the I.domain.NET <http://i.domain.net/> <http://I.domain.NET <http://i.domain.net/>> > > IPA > > > > > CA cert. By setting the clock back I managed to get those to renew, > > now > > > > > it seems I just need to get tomcat-pki to start. > > > > > > > > > > The error is: > > > > > > > > > > Internal Database Error encountered: Could not connect to LDAP server > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> <http://xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/>> port 636 Error > > > > > netscape.ldap.LDAPException: Unable to create socket: > > > > > org.mozilla.jss.ssl.SSLSocketException: > > > > > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: > > > > > (-12195) Peer does not recognize and trust the CA that issued your > > > > > certificate. (-1) > > > > > > > > > > certutil -d /etc/pki/pki-tomcat/alias -L > > > > > > > > > > Certificate Nickname Trust > > > > > Attributes > > > > > > > > > > SSL,S/MIME,JAR/XPI > > > > > > > > > > Server-Cert cert-pki-ca u,u,u > > > > > ocspSigningCert cert-pki-ca u,u,u > > > > > O=domain,ST=Arizona,C=US CT,C,C > > > > > auditSigningCert cert-pki-ca u,u,Pu > > > > > subsystemCert cert-pki-ca u,u,u > > > > > caSigningCert cert-pki-ca > > CTu,Cu,Cu > > > > > > > > > > These are all set to expire in 2020 or beyond. > > > > > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > > > > > Certificate Nickname Trust > > > > > Attributes > > > > > > > > > > SSL,S/MIME,JAR/XPI > > > > > > > > > > Signing-Cert u,u,u > > > > > O=xrs444,ST=Arizona,C=US CT,C,C > > > > > I.XRS444.NET <http://i.xrs444.net/> <http://I.XRS444.NET <http://i.xrs444.net/>> IPA CA > > > > > CT,C,C > > > > > Server-Cert u,u,u > > > > > > > > > > I.XRS444.NET <http://i.xrs444.net/> <http://I.XRS444.NET <http://i.xrs444.net/>> IPA CA and Signing-Cert are the > > > > > expired certs here. > > > > > > > > Don't worry about Signing-Cert. It is the cert used to sign the jar > > file > > > > used to autoconfigure Firefox. You should never need to re-sign one > > > > again (and this method isn't allowed in modern Firefox anyway). > > > > > > > > rob > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud < > > flo@redhat.com <mailto:flo@redhat.com> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com>>> wrote: > > > > > > > > > > On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > > > > > > After some fiddling with dates some more I seem to have the > > HTTPD > > > > > cert > > > > > > in sync, however it appears the cert signing cert is expired. > > > > > > > > > > > > named also says it's starting, but doesn't seem to want to > > respond. > > > > > > > > > > > > I don't have time to dig into it more tonight, but let me know > > what > > > > > > other information or tests I can run and I'll get them posted > > > > > tomorrow. > > > > > > > > > > > > Thanks all. > > > > > > > > > > > > Thomas > > > > > > > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>> wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > I think this is everything (domain name changed to protect > > the > > > > > > guilty!): > > > > > > > > > > > > https://pastebin.com/bF1KR7VJ > > > > > > > > > > > Hi Thomas, > > > > > > > > > > in the provided pastebin, the error 'certutil: function failed: > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an > > old, > > > > > unsupported format' can be easily explained: there is a typo in > > the > > > > > directory path. > > > > > You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n > > > > <nickname> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). > > > > > > > > > > You mention that the cert signing cert is expired, can you > > clarify > > > > > which > > > > > certificate this is? Please provide the subject name, certificate > > > > > nickname and location. > > > > > > > > > > Flo > > > > > > I pulled the same on the replica, which appears to be > > playing > > > > > up too > > > > > > in a similar fashion. > > > > > > > > > > > > I did just notice the date on the replica is out, I never > > set > > > > it > > > > > > back when I was trying to get the cert to renew. > > > > > > > > > > > > Let me know if you need anything else. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Thomas > > > > > > > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>> > > > > wrote: > > > > > > > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas > > Letherby > > > > via > > > > > > FreeIPA-users wrote: > > > > > > > Hello all, > > > > > > > I had an issue a short while ago with a replica > > which > > > > > turned > > > > > > out to be an > > > > > > > expired certificate which I renewed and all seemed > > good. > > > > > > > > > > > > > > Seemed... > > > > > > > > > > > > > > It now appears that although the certificate > > renewed as > > > > > seen > > > > > > by getcert > > > > > > > -list, it didn't update /etc/httpd/alias and so the > > > > > httpd and > > > > > > tomcat-pki > > > > > > > services won't start unless I set the date to > > before the > > > > > > certificate > > > > > > > expired, and even then sometimes the httpd error_log > > > > shows: > > > > > > > Unable to verify certificate 'Server-Cert'. Add > > > > > > "NSSEnforceValidCerts off" > > > > > > > to nss.conf so the server can start until the > > problem > > > > > can be > > > > > > resolved. > > > > > > > and the service fails to start. > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > Can you please show `getcert list` output on the > > server in > > > > > question, > > > > > > as well as the output of > > > > > > > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > > > > > > > and > > > > > > > > > > > > certutil -d /etc/pki/pki-tomcatd/alias -L > > <nickname> > > > > > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias > > NSSDB. > > > > > > > > > > > > And Certmonger journal output. And pki debug log > > > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > > > > > It is strange that `getcert list' shows an up to date > > > > > certificate > > > > > > while the actual certificate that is being tracked is > > > > > expired... > > > > > > > > > > > > Thanks, > > > > > > Fraser > > > > > > > > > > > > > I've tried resubmitting the certificate, and it > > doesn't > > > > > seem > > > > > > to throw an > > > > > > > error, but it doesn't update /alias either. > > > > > > > Trying to access the server via the web page shows > > the > > > > old > > > > > > certificate > > > > > > > still in use. > > > > > > > I see the same certificate error with the replica > > > > server, > > > > > > which was freshly > > > > > > > rebuilt and added last week. > > > > > > > I've doubtless dug further into the hole trying to > > > > > > troubleshoot this, so I > > > > > > > probably need to start from the beginning again, > > and a > > > > > > pointer in the right > > > > > > > direction would be a great help! > > > > > > > > > > > > > > A getcert list shows all the certificates expiry > > dates > > > > well > > > > > > into the future. > > > > > > > > > > > > > > How can I get the certs back in sync? I've found a > > few > > > > > guides > > > > > > and most seem > > > > > > > to be for earlier versions, and I'm not sure if > > they're > > > > > still > > > > > > current. > > > > > > > > > > > > > > I can post whatever logs you think will help, I'm > > > > > afraid I'm > > > > > > not familiar > > > > > > > enough with them all to tell which are the most > > > > > relevant. Is > > > > > > there a guide > > > > > > > for the logs? > > > > > > > > > > > > > > Thanks for any help you can give, > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > _______________________________________________ > > > > > > > FreeIPA-users mailing list -- > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > > > > To unsubscribe send an email to > > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> > > > > > > > Fedora Code of Conduct: > > > > > > https://getfedora.org/code-of-conduct.html > > > > > > > List Guidelines: > > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > > List Archives: > > > > > > > > > > > > > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > FreeIPA-users mailing list -- > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > > To unsubscribe send an email to > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > > Fedora Code of Conduct: > > https://getfedora.org/code-of-conduct.html > > > > > > List Guidelines: > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > List Archives: > > > > > > > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ > > > > > > > > > > > > > > > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Z2CWAOM4HBHXWBCQRFJXFCHMOEBRFPPO/
Here's the full listing from slap-d and pki-tomcat:
Is there any other logs that could help right now?
And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this!
Thomas
On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Well, after poking around with the dates and a few restarts of services, IPA now starts seemingly cleanly at the current date, although the clients still don't seem to want to trust the CA, and I'm still seeing the old cert crop up.
If I look at the cert that wasn't updating before, it now seems to contain three certs, the expired one and two new with much longer expiry dates.
[root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n "I.DOMAIN.NET http://I.DOMAIN.NET IPA CA" | grep Not Not Before: Sun Jun 17 09:06:38 2018 Not After : Thu Jun 17 09:06:38 2038 Not Before: Sun Jun 17 07:24:26 2018 Not After : Thu Jun 17 07:24:26 2038 Not Before: Thu Jun 08 06:51:04 2017 Not After : Mon Jun 18 06:51:04 2018
Is this correct, or has it not updated the certificate correctly, if so, how do I clean it up?
This is rather confusing output. I think we need to see the full certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point?
rob
Thanks,
Thomas
On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS <christophe.trefois@uni.lu mailto:christophe.trefois@uni.lu> wrote:
From that I know you could trigger a refresh by restarting
certmonger.
On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> wrote: Hello Fraser, As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired: certutil -d /etc/pki/pki-tomcat/alias -L Up to date certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET <http://i.domain.net/> IPA CA certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET <http://i.domain.net/> IPA CA getcert-list all up to date. ipa-getcert list all up to date ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://i.domain.net/> IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours? Thomas On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote: On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: > Hello Fraser, > > The serial numbers appear to match, but if I run ipa-certupdate I get the > following: > > ipa-certupdate > trying https://server1.i.domain.net/ipa/json > Connection to https://server1.i.domain.net/ipa/json failed with [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) > > Tomcat is the only service that appears to be failing with the following > error: > > Internal Database Error encountered: Could not connect to LDAP server host > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to > create socket: org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8181) > Peer's Certificate has expired. (-1) > > But it should now be valid as I set the date back. If I set the date to > today I get this error: > > Internal Database Error encountered: Could not connect to LDAP server host > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to > create socket: org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) > Peer does not recognize and trust the CA that issued your certificate. (-1) > > Looks like it can't load because the certificate it uses isn't valid, if I > roll the clock back so the CA cert is, the certificate Tomcat is using > isn't valid and if I roll forward the CA cert isn't. > > How can I break this catch 22? > Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server certificate? In either case, you can look in the Dogtag certificate
repository
(ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER
certificate
data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using certutil -d <nssdb-path> -A -i <cert-path> If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry
to
match the "current" certificate. HTH, Fraser > Thanks, > > Thomas > > > > > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > wrote: > > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote: > > > Hello all, > > > > > > Here's the info: > > > > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L > > > > > > Certificate Nickname Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > > > > Server-Cert u,u,u > > > O=domain,ST=Arizona,C=US CT,C,C > > > I.domain.NET <http://i.domain.net/> IPA CA CT,C,C > > > > > > I.domain.NET <http://i.domain.net/> IPA CA is out of date for those. > > > > > Try running ipa-certupdate. It will update the IPA CA certificate > > in the various trust stores including the DS NSSDB. > > > > It reads the certificates from > > > > cn=YOUR.DOMAIN IPA
CA,cn=certificates,cn=ipa,cn=etc,{basedn}
> > > > so you should probably check that the certificate in that entry is > > up to date also. > > > > Cheers, > > Fraser > > > > > certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' > > -a > > > Not After : Fri Jun 05 01:32:01 2020 > > > Matches > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > > > > > > Thomas > > > > > > > > > > > > > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> > > wrote: > > > > > > > Thomas Letherby via FreeIPA-users wrote: > > > > > Hello Florence, > > > > > > > > > > It was the Signing-Cert and the I.domain.NET <http://i.domain.net/> <http://I.domain.NET <http://i.domain.net/>> > > IPA > > > > > CA cert. By setting the clock back I managed to get those to renew, > > now > > > > > it seems I just need to get tomcat-pki to start. > > > > > > > > > > The error is: > > > > > > > > > > Internal Database Error encountered: Could not connect to LDAP server > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> <http://xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/>> port 636 Error > > > > > netscape.ldap.LDAPException: Unable to create socket: > > > > > org.mozilla.jss.ssl.SSLSocketException: > > > > > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: > > > > > (-12195) Peer does not recognize and trust the CA that issued your > > > > > certificate. (-1) > > > > > > > > > > certutil -d /etc/pki/pki-tomcat/alias -L > > > > > > > > > > Certificate Nickname Trust > > > > > Attributes > > > > > > > > > > SSL,S/MIME,JAR/XPI > > > > > > > > > > Server-Cert cert-pki-ca u,u,u > > > > > ocspSigningCert cert-pki-ca u,u,u > > > > > O=domain,ST=Arizona,C=US CT,C,C > > > > > auditSigningCert cert-pki-ca u,u,Pu > > > > > subsystemCert cert-pki-ca u,u,u > > > > > caSigningCert cert-pki-ca > > CTu,Cu,Cu > > > > > > > > > > These are all set to expire in 2020 or beyond. > > > > > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > > > > > Certificate Nickname Trust > > > > > Attributes > > > > > > > > > > SSL,S/MIME,JAR/XPI > > > > > > > > > > Signing-Cert u,u,u > > > > > O=xrs444,ST=Arizona,C=US CT,C,C > > > > > I.XRS444.NET <http://i.xrs444.net/> <http://I.XRS444.NET <http://i.xrs444.net/>> IPA CA > > > > > CT,C,C > > > > > Server-Cert u,u,u > > > > > > > > > > I.XRS444.NET <http://i.xrs444.net/> <http://I.XRS444.NET <http://i.xrs444.net/>> IPA CA and Signing-Cert are the > > > > > expired certs here. > > > > > > > > Don't worry about Signing-Cert. It is the cert used to sign the jar > > file > > > > used to autoconfigure Firefox. You should never need to re-sign one > > > > again (and this method isn't allowed in modern Firefox anyway). > > > > > > > > rob > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence
Blanc-Renaud <
> > flo@redhat.com <mailto:flo@redhat.com> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com>>>
wrote:
> > > > > > > > > > On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > > > > > > After some fiddling with dates some more I seem to have the > > HTTPD > > > > > cert > > > > > > in sync, however it appears the cert signing cert is expired. > > > > > > > > > > > > named also says it's starting, but doesn't seem to want to > > respond. > > > > > > > > > > > > I don't have time to dig into it more tonight, but let me know > > what > > > > > > other information or tests I can run and I'll get them posted > > > > > tomorrow. > > > > > > > > > > > > Thanks all. > > > > > > > > > > > > Thomas > > > > > > > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby
<
> > xrs444@xrs444.net <mailto:xrs444@xrs444.net> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>> wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > I think this is everything (domain name changed to protect > > the > > > > > > guilty!): > > > > > > > > > > > > https://pastebin.com/bF1KR7VJ > > > > > > > > > > > Hi Thomas, > > > > > > > > > > in the provided pastebin, the error 'certutil: function failed: > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an > > old, > > > > > unsupported format' can be easily explained: there is a typo in > > the > > > > > directory path. > > > > > You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n > > > > <nickname> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). > > > > > > > > > > You mention that the cert signing cert is expired, can you > > clarify > > > > > which > > > > > certificate this is? Please provide the subject name, certificate > > > > > nickname and location. > > > > > > > > > > Flo > > > > > > I pulled the same on the replica, which appears to be > > playing > > > > > up too > > > > > > in a similar fashion. > > > > > > > > > > > > I did just notice the date on the replica is out, I never > > set > > > > it > > > > > > back when I was trying to get the cert to renew. > > > > > > > > > > > > Let me know if you need anything else. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Thomas > > > > > > > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>> > > > > wrote: > > > > > > > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas > > Letherby > > > > via > > > > > > FreeIPA-users wrote: > > > > > > > Hello all, > > > > > > > I had an issue a short while ago with a replica > > which > > > > > turned > > > > > > out to be an > > > > > > > expired certificate which I renewed and all seemed > > good. > > > > > > > > > > > > > > Seemed... > > > > > > > > > > > > > > It now appears that although the certificate > > renewed as > > > > > seen > > > > > > by getcert > > > > > > > -list, it didn't update /etc/httpd/alias and so the > > > > > httpd and > > > > > > tomcat-pki > > > > > > > services won't start unless I set the date to > > before the > > > > > > certificate > > > > > > > expired, and even then sometimes the httpd error_log > > > > shows: > > > > > > > Unable to verify certificate 'Server-Cert'. Add > > > > > > "NSSEnforceValidCerts off" > > > > > > > to nss.conf so the server can start until the > > problem > > > > > can be > > > > > > resolved. > > > > > > > and the service fails to start. > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > Can you please show `getcert list` output on the > > server in > > > > > question, > > > > > > as well as the output of > > > > > > > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > > > > > > > and > > > > > > > > > > > > certutil -d /etc/pki/pki-tomcatd/alias -L > > <nickname> > > > > > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias > > NSSDB. > > > > > > > > > > > > And Certmonger journal output. And pki debug log > > > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > > > > > It is strange that `getcert list' shows an up to date > > > > > certificate > > > > > > while the actual certificate that is being tracked is > > > > > expired... > > > > > > > > > > > > Thanks, > > > > > > Fraser > > > > > > > > > > > > > I've tried resubmitting the certificate, and it > > doesn't > > > > > seem > > > > > > to throw an > > > > > > > error, but it doesn't update /alias either. > > > > > > > Trying to access the server via the web page shows > > the > > > > old > > > > > > certificate > > > > > > > still in use. > > > > > > > I see the same certificate error with the replica > > > > server, > > > > > > which was freshly > > > > > > > rebuilt and added last week. > > > > > > > I've doubtless dug further into the hole trying to > > > > > > troubleshoot this, so I > > > > > > > probably need to start from the beginning again, > > and a > > > > > > pointer in the right > > > > > > > direction would be a great help! > > > > > > > > > > > > > > A getcert list shows all the certificates expiry > > dates > > > > well > > > > > > into the future. > > > > > > > > > > > > > > How can I get the certs back in sync? I've found a > > few > > > > > guides > > > > > > and most seem > > > > > > > to be for earlier versions, and I'm not sure if > > they're > > > > > still > > > > > > current. > > > > > > > > > > > > > > I can post whatever logs you think will help, I'm > > > > > afraid I'm > > > > > > not familiar > > > > > > > enough with them all to tell which are the most > > > > > relevant. Is > > > > > > there a guide > > > > > > > for the logs? > > > > > > > > > > > > > > Thanks for any help you can give, > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > _______________________________________________ > > > > > > > FreeIPA-users mailing list -- > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > > > > To unsubscribe send an email to > > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> > > > > > > > Fedora Code of Conduct: > > > > > >
https://getfedora.org/code-of-conduct.html
> > > > > > > List Guidelines: > > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > > List Archives: > > > > > > > > > > > > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > FreeIPA-users mailing list -- > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > > To unsubscribe send an email to > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > > Fedora Code of Conduct: > > https://getfedora.org/code-of-conduct.html > > > > > > List Guidelines: > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > List Archives: > > > > > > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > > > > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it should have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
Is this correct? If I have to there's not many certificates issued, and replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy to try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's not going to be the end of the world.
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby xrs444@xrs444.net wrote:
Here's the full listing from slap-d and pki-tomcat:
Is there any other logs that could help right now?
And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this!
Thomas
On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Well, after poking around with the dates and a few restarts of services, IPA now starts seemingly cleanly at the current date, although the clients still don't seem to want to trust the CA, and I'm still seeing the old cert crop up.
If I look at the cert that wasn't updating before, it now seems to contain three certs, the expired one and two new with much longer expiry dates.
[root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n "I.DOMAIN.NET http://I.DOMAIN.NET IPA CA" | grep Not Not Before: Sun Jun 17 09:06:38 2018 Not After : Thu Jun 17 09:06:38 2038 Not Before: Sun Jun 17 07:24:26 2018 Not After : Thu Jun 17 07:24:26 2038 Not Before: Thu Jun 08 06:51:04 2017 Not After : Mon Jun 18 06:51:04 2018
Is this correct, or has it not updated the certificate correctly, if so, how do I clean it up?
This is rather confusing output. I think we need to see the full certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point?
rob
Thanks,
Thomas
On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS <christophe.trefois@uni.lu mailto:christophe.trefois@uni.lu> wrote:
From that I know you could trigger a refresh by restarting
certmonger.
On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> wrote: Hello Fraser, As I've been playing around with this before I dig in further I pulled the expiry for the certificates across all the places I know to look, if I have a cert listed, it's expired: certutil -d /etc/pki/pki-tomcat/alias -L Up to date certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L I.DOMAIN.NET <http://i.domain.net/> IPA CA certutil -d /etc/httpd/alias -L Signing-Cert I.DOMAIN.NET <http://i.domain.net/> IPA CA getcert-list all up to date. ipa-getcert list all up to date ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://i.domain.net/> IPA CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" Expired ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate 1 - Expired 2 - Expired 3 - In date I've managed to narrow down the expiries to a crossover of one day, and setting the date to that day allows Tomcat-PKI to start, but the above results show that the certs haven't updated yet, but they may do in the next few hours? Thomas On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote: On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby
wrote:
> Hello Fraser, > > The serial numbers appear to match, but if I run ipa-certupdate I get the > following: > > ipa-certupdate > trying https://server1.i.domain.net/ipa/json > Connection to https://server1.i.domain.net/ipa/json failed with [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) > > Tomcat is the only service that appears to be failing with the following > error: > > Internal Database Error encountered: Could not connect to LDAP server host > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to > create socket: org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8181) > Peer's Certificate has expired. (-1) > > But it should now be valid as I set the date back. If I set the date to > today I get this error: > > Internal Database Error encountered: Could not connect to LDAP server host > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636 Error netscape.ldap.LDAPException: Unable to > create socket: org.mozilla.jss.ssl.SSLSocketException: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-12195) > Peer does not recognize and trust the CA that issued your certificate. (-1) > > Looks like it can't load because the certificate it uses isn't valid, if I > roll the clock back so the CA cert is, the certificate Tomcat is using > isn't valid and if I roll forward the CA cert isn't. > > How can I break this catch 22? > Which is the not-yet-valid certificate at the time to which you rolled back? The subsystemCert or the 389DS server
certificate?
In either case, you can look in the Dogtag certificate
repository
(ou=certificateRepository,ou=ca,o=ipaca) for a version of the certificate that is valid at the relevant time. Copy the cert data (you can base64-decode the value to get the binary DER
certificate
data). Then you can delete the not-yet-valid-at-that-time certificate from the NSSDB and add the appropriate certificate using certutil -d <nssdb-path> -A -i <cert-path> If the certificate in question is the Dogtag subsystemCert, you will furthermore need to fix up the data in the uid=pkidbuser entry
to
match the "current" certificate. HTH, Fraser > Thanks, > > Thomas > > > > > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > wrote: > > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby wrote: > > > Hello all, > > > > > > Here's the info: > > > > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L > > > > > > Certificate Nickname Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > > > > Server-Cert u,u,u > > > O=domain,ST=Arizona,C=US CT,C,C > > > I.domain.NET <http://i.domain.net/> IPA CA CT,C,C > > > > > > I.domain.NET <http://i.domain.net/> IPA CA is out of date for those. > > > > > Try running ipa-certupdate. It will update the IPA CA certificate > > in the various trust stores including the DS NSSDB. > > > > It reads the certificates from > > > > cn=YOUR.DOMAIN IPA
CA,cn=certificates,cn=ipa,cn=etc,{basedn}
> > > > so you should probably check that the certificate in that entry is > > up to date also. > > > > Cheers, > > Fraser > > > > > certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' > > -a > > > Not After : Fri Jun 05 01:32:01 2020 > > > Matches > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > > > > > > Thomas > > > > > > > > > > > > > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> > > wrote: > > > > > > > Thomas Letherby via FreeIPA-users wrote: > > > > > Hello Florence, > > > > > > > > > > It was the Signing-Cert and the I.domain.NET <http://i.domain.net/> <http://I.domain.NET <http://i.domain.net/>> > > IPA > > > > > CA cert. By setting the clock back I managed to get those to renew, > > now > > > > > it seems I just need to get tomcat-pki to start. > > > > > > > > > > The error is: > > > > > > > > > > Internal Database Error encountered: Could not connect to LDAP server > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> <http://xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/>> port 636 Error > > > > > netscape.ldap.LDAPException: Unable to create socket: > > > > > org.mozilla.jss.ssl.SSLSocketException: > > > > > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: > > > > > (-12195) Peer does not recognize and trust the CA that issued your > > > > > certificate. (-1) > > > > > > > > > > certutil -d /etc/pki/pki-tomcat/alias -L > > > > > > > > > > Certificate Nickname Trust > > > > > Attributes > > > > > > > > > > SSL,S/MIME,JAR/XPI > > > > > > > > > > Server-Cert cert-pki-ca u,u,u > > > > > ocspSigningCert cert-pki-ca u,u,u > > > > > O=domain,ST=Arizona,C=US CT,C,C > > > > > auditSigningCert cert-pki-ca u,u,Pu > > > > > subsystemCert cert-pki-ca u,u,u > > > > > caSigningCert cert-pki-ca > > CTu,Cu,Cu > > > > > > > > > > These are all set to expire in 2020 or beyond. > > > > > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > > > > > Certificate Nickname Trust > > > > > Attributes > > > > > > > > > > SSL,S/MIME,JAR/XPI > > > > > > > > > > Signing-Cert u,u,u > > > > > O=xrs444,ST=Arizona,C=US CT,C,C > > > > > I.XRS444.NET <http://i.xrs444.net/> <http://I.XRS444.NET <http://i.xrs444.net/>> IPA CA > > > > > CT,C,C > > > > > Server-Cert u,u,u > > > > > > > > > > I.XRS444.NET <http://i.xrs444.net/> <http://I.XRS444.NET <http://i.xrs444.net/>> IPA CA and Signing-Cert are the > > > > > expired certs here. > > > > > > > > Don't worry about Signing-Cert. It is the cert used to sign the jar > > file > > > > used to autoconfigure Firefox. You should never need to re-sign one > > > > again (and this method isn't allowed in modern Firefox anyway). > > > > > > > > rob > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence
Blanc-Renaud <
> > flo@redhat.com <mailto:flo@redhat.com> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com>>>
wrote:
> > > > > > > > > > On 06/27/2018 07:02 AM, Thomas Letherby via FreeIPA-users wrote: > > > > > > After some fiddling with dates some more I seem to have the > > HTTPD > > > > > cert > > > > > > in sync, however it appears the cert signing cert is expired. > > > > > > > > > > > > named also says it's starting, but doesn't seem to want to > > respond. > > > > > > > > > > > > I don't have time to dig into it more tonight, but let me know > > what > > > > > > other information or tests I can run and I'll get them posted > > > > > tomorrow. > > > > > > > > > > > > Thanks all. > > > > > > > > > > > > Thomas > > > > > > > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas
Letherby <
> > xrs444@xrs444.net <mailto:xrs444@xrs444.net> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>> wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > I think this is everything (domain name changed to protect > > the > > > > > > guilty!): > > > > > > > > > > > > https://pastebin.com/bF1KR7VJ > > > > > > > > > > > Hi Thomas, > > > > > > > > > > in the provided pastebin, the error 'certutil: function failed: > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an > > old, > > > > > unsupported format' can be easily explained: there is a typo in > > the > > > > > directory path. > > > > > You can try with certutil -d /etc/pki/pki-tomcat/alias -L -n > > > > <nickname> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). > > > > > > > > > > You mention that the cert signing cert is expired, can you > > clarify > > > > > which > > > > > certificate this is? Please provide the subject name, certificate > > > > > nickname and location. > > > > > > > > > > Flo > > > > > > I pulled the same on the replica, which appears to be > > playing > > > > > up too > > > > > > in a similar fashion. > > > > > > > > > > > > I did just notice the date on the replica is out, I never > > set > > > > it > > > > > > back when I was trying to get the cert to renew. > > > > > > > > > > > > Let me know if you need anything else. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Thomas > > > > > > > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser Tweedale > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>> > > > > wrote: > > > > > > > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM -0700, Thomas > > Letherby > > > > via > > > > > > FreeIPA-users wrote: > > > > > > > Hello all, > > > > > > > I had an issue a short while ago with a replica > > which > > > > > turned > > > > > > out to be an > > > > > > > expired certificate which I renewed and all seemed > > good. > > > > > > > > > > > > > > Seemed... > > > > > > > > > > > > > > It now appears that although the certificate > > renewed as > > > > > seen > > > > > > by getcert > > > > > > > -list, it didn't update /etc/httpd/alias and so the > > > > > httpd and > > > > > > tomcat-pki > > > > > > > services won't start unless I set the date to > > before the > > > > > > certificate > > > > > > > expired, and even then sometimes the httpd error_log > > > > shows: > > > > > > > Unable to verify certificate 'Server-Cert'. Add > > > > > > "NSSEnforceValidCerts off" > > > > > > > to nss.conf so the server can start until the > > problem > > > > > can be > > > > > > resolved. > > > > > > > and the service fails to start. > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > Can you please show `getcert list` output on the > > server in > > > > > question, > > > > > > as well as the output of > > > > > > > > > > > > certutil -d /etc/httpd/alias -L Server-Cert > > > > > > > > > > > > and > > > > > > > > > > > > certutil -d /etc/pki/pki-tomcatd/alias -L > > <nickname> > > > > > > > > > > > > for each nickname in the /etc/pki/pki-tomcatd/alias > > NSSDB. > > > > > > > > > > > > And Certmonger journal output. And pki debug log > > > > > > /var/log/pki/pki-tomcat/ca/debug. > > > > > > > > > > > > It is strange that `getcert list' shows an up to date > > > > > certificate > > > > > > while the actual certificate that is being tracked is > > > > > expired... > > > > > > > > > > > > Thanks, > > > > > > Fraser > > > > > > > > > > > > > I've tried resubmitting the certificate, and it > > doesn't > > > > > seem > > > > > > to throw an > > > > > > > error, but it doesn't update /alias either. > > > > > > > Trying to access the server via the web page shows > > the > > > > old > > > > > > certificate > > > > > > > still in use. > > > > > > > I see the same certificate error with the replica > > > > server, > > > > > > which was freshly > > > > > > > rebuilt and added last week. > > > > > > > I've doubtless dug further into the hole trying to > > > > > > troubleshoot this, so I > > > > > > > probably need to start from the beginning again, > > and a > > > > > > pointer in the right > > > > > > > direction would be a great help! > > > > > > > > > > > > > > A getcert list shows all the certificates expiry > > dates > > > > well > > > > > > into the future. > > > > > > > > > > > > > > How can I get the certs back in sync? I've found a > > few > > > > > guides > > > > > > and most seem > > > > > > > to be for earlier versions, and I'm not sure if > > they're > > > > > still > > > > > > current. > > > > > > > > > > > > > > I can post whatever logs you think will help, I'm > > > > > afraid I'm > > > > > > not familiar > > > > > > > enough with them all to tell which are the most > > > > > relevant. Is > > > > > > there a guide > > > > > > > for the logs? > > > > > > > > > > > > > > Thanks for any help you can give, > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > _______________________________________________ > > > > > > > FreeIPA-users mailing list -- > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> > > > > > > > To unsubscribe send an email to > > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> > > > > > > > Fedora Code of Conduct: > > > > > >
https://getfedora.org/code-of-conduct.html
> > > > > > > List Guidelines: > > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > > List Archives: > > > > > > > > > > > > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > FreeIPA-users mailing list -- > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> > > > > > > To unsubscribe send an email to > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > > > > Fedora Code of Conduct: > > https://getfedora.org/code-of-conduct.html > > > > > > List Guidelines: > > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > List Archives: > > > > > > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> > > > > > To unsubscribe send an email to > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> > > > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > List Archives: > > > > > >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
> > > > > > > > > > > > > > > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
Thomas Letherby wrote:
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal%C2%A0it should have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
You almost NEVER want to run this command. This renews the CA certificate. Nothing else. There is really no point. It is good for another 20 years.
Is this correct? If I have to there's not many certificates issued, and replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy to try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's not going to be the end of the world.
I'm sorry. I've had your paste open for a week now and keep forgetting to respond :-(
So you somehow have a bogus CA entry, serial # 4097. I'm not sure where that came from, I assume some self-signed CA of yours. The issuer is O=DOMAIN,ST=Arizona,C=US. It needs to go.
Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You can never be too careful.
What I'd recommend is to delete all the CA certs using certutil -D -d /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three times.
Then run ipa-certupdate. This should refresh the list with the proper CAs. certutil -L to show them again. There should be only one. If Apache is working you can use that cert database, /etc/httpd/alias, for comparison purposes.
For extra points you can verify it without starting the service:
# certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f /etc/dirsrv/slapd-INSTANCE/pwdfile.txt
So you have an existing Server-Cert but I can't really be sure which CA signed it. The above will tell you if it is currently trusted. It is good for another 2 years.
rob
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Here's the full listing from slap-d and pki-tomcat: https://pastebin.com/vWf2WVkN Is there any other logs that could help right now? And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this! Thomas On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> wrote: Thomas Letherby wrote: > Well, after poking around with the dates and a few restarts of services, > IPA now starts seemingly cleanly at the current date, although the > clients still don't seem to want to trust the CA, and I'm still seeing > the old cert crop up. > > If I look at the cert that wasn't updating before, it now seems to > contain three certs, the expired one and two new with much longer expiry > dates. > > [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET> IPA CA" | grep Not > Not Before: Sun Jun 17 09:06:38 2018 > Not After : Thu Jun 17 09:06:38 2038 > Not Before: Sun Jun 17 07:24:26 2018 > Not After : Thu Jun 17 07:24:26 2038 > Not Before: Thu Jun 08 06:51:04 2017 > Not After : Mon Jun 18 06:51:04 2018 > > Is this correct, or has it not updated the certificate correctly, if so, > how do I clean it up? This is rather confusing output. I think we need to see the full certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point? rob > > Thanks, > > Thomas > > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS > <christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu> <mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>>> wrote: > > From that I know you could trigger a refresh by restarting certmonger. > >> On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users >> <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> >> Hello Fraser, >> >> As I've been playing around with this before I dig in further I >> pulled the expiry for the certificates across all the places I >> know to look, if I have a cert listed, it's expired: >> >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> certutil -d /etc/httpd/alias -L >> Signing-Cert >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> getcert-list all up to date. >> >> ipa-getcert list all up to date >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> <http://i.domain.net/> IPA >> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" >> Expired >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate >> 1 - Expired >> 2 - Expired >> 3 - In date >> >> I've managed to narrow down the expiries to a crossover of one >> day, and setting the date to that day allows Tomcat-PKI to start, >> but the above results show that the certs haven't updated yet, but >> they may do in the next few hours? >> >> Thomas >> >> >> >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> wrote: >> >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: >> > Hello Fraser, >> > >> > The serial numbers appear to match, but if I run >> ipa-certupdate I get the >> > following: >> > >> > ipa-certupdate >> > trying https://server1.i.domain.net/ipa/json >> > Connection to https://server1.i.domain.net/ipa/json failed >> with [SSL: >> > CERTIFICATE_VERIFY_FAILED] certificate verify failed >> (_ssl.c:579) >> > >> > Tomcat is the only service that appears to be failing with >> the following >> > error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket: org.mozilla.jss.ssl.SSLSocketException: >> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-8181) >> > Peer's Certificate has expired. (-1) >> > >> > But it should now be valid as I set the date back. If I set >> the date to >> > today I get this error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket: org.mozilla.jss.ssl.SSLSocketException: >> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-12195) >> > Peer does not recognize and trust the CA that issued your >> certificate. (-1) >> > >> > Looks like it can't load because the certificate it uses >> isn't valid, if I >> > roll the clock back so the CA cert is, the certificate >> Tomcat is using >> > isn't valid and if I roll forward the CA cert isn't. >> > >> > How can I break this catch 22? >> > >> Which is the not-yet-valid certificate at the time to which you >> rolled back? The subsystemCert or the 389DS server certificate? >> >> In either case, you can look in the Dogtag certificate repository >> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the >> certificate that is valid at the relevant time. Copy the cert >> data >> (you can base64-decode the value to get the binary DER certificate >> data). Then you can delete the not-yet-valid-at-that-time >> certificate from the NSSDB and add the appropriate certificate >> using >> >> certutil -d <nssdb-path> -A -i <cert-path> >> >> If the certificate in question is the Dogtag subsystemCert, >> you will >> furthermore need to fix up the data in the uid=pkidbuser entry to >> match the "current" certificate. >> >> HTH, >> Fraser >> >> >> > Thanks, >> > >> > Thomas >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > wrote: >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby >> wrote: >> > > > Hello all, >> > > > >> > > > Here's the info: >> > > > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L >> > > > >> > > > Certificate Nickname >> Trust >> > > > Attributes >> > > > >> > > > SSL,S/MIME,JAR/XPI >> > > > >> > > > Server-Cert >> u,u,u >> > > > O=domain,ST=Arizona,C=US >> CT,C,C >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA >> CT,C,C >> > > > >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA is out of >> date for those. >> > > > >> > > Try running ipa-certupdate. It will update the IPA CA >> certificate >> > > in the various trust stores including the DS NSSDB. >> > > >> > > It reads the certificates from >> > > >> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > > >> > > so you should probably check that the certificate in that >> entry is >> > > up to date also. >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> > > -a >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > > > Matches >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" >> usercertificate >> > > > >> > > > Thomas >> > > > >> > > > >> > > > >> > > > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden >> <rcritten@redhat.com <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >> > > wrote: >> > > > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > > > > > Hello Florence, >> > > > > > >> > > > > > It was the Signing-Cert and the I.domain.NET <http://I.domain.NET> >> <http://i.domain.net/> <http://I.domain.NET >> <http://i.domain.net/>> >> > > IPA >> > > > > > CA cert. By setting the clock back I managed to get >> those to renew, >> > > now >> > > > > > it seems I just need to get tomcat-pki to start. >> > > > > > >> > > > > > The error is: >> > > > > > >> > > > > > Internal Database Error encountered: Could not >> connect to LDAP server >> > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> <http://xipa1.i.xrs444.net/> <http://xipa1.i.xrs444.net >> <http://xipa1.i.xrs444.net/>> port 636 Error >> > > > > > netscape.ldap.LDAPException: Unable to create socket: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> SSL_ForceHandshake failed: >> > > > > > (-12195) Peer does not recognize and trust the CA >> that issued your >> > > > > > certificate. (-1) >> > > > > > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > > > > > >> > > > > > Certificate Nickname >> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Server-Cert cert-pki-ca >> u,u,u >> > > > > > ocspSigningCert cert-pki-ca >> u,u,u >> > > > > > O=domain,ST=Arizona,C=US >> CT,C,C >> > > > > > auditSigningCert cert-pki-ca >> u,u,Pu >> > > > > > subsystemCert cert-pki-ca >> u,u,u >> > > > > > caSigningCert cert-pki-ca >> > > CTu,Cu,Cu >> > > > > > >> > > > > > These are all set to expire in 2020 or beyond. >> > > > > > >> > > > > > certutil -d /etc/httpd/alias -L Server-Cert >> > > > > > >> > > > > > Certificate Nickname >> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Signing-Cert >> u,u,u >> > > > > > O=xrs444,ST=Arizona,C=US >> CT,C,C >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA >> > > > > > CT,C,C >> > > > > > Server-Cert >> u,u,u >> > > > > > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA and Signing-Cert are the >> > > > > > expired certs here. >> > > > > >> > > > > Don't worry about Signing-Cert. It is the cert used to >> sign the jar >> > > file >> > > > > used to autoconfigure Firefox. You should never need >> to re-sign one >> > > > > again (and this method isn't allowed in modern Firefox >> anyway). >> > > > > >> > > > > rob >> > > > > >> > > > > > >> > > > > > Thomas >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud < >> > > flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>> >> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>>>> wrote: >> > > > > > >> > > > > > On 06/27/2018 07:02 AM, Thomas Letherby via >> FreeIPA-users wrote: >> > > > > > > After some fiddling with dates some more I >> seem to have the >> > > HTTPD >> > > > > > cert >> > > > > > > in sync, however it appears the cert signing >> cert is expired. >> > > > > > > >> > > > > > > named also says it's starting, but doesn't >> seem to want to >> > > respond. >> > > > > > > >> > > > > > > I don't have time to dig into it more tonight, >> but let me know >> > > what >> > > > > > > other information or tests I can run and I'll >> get them posted >> > > > > > tomorrow. >> > > > > > > >> > > > > > > Thanks all. >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < >> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> >> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>> >> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>>> wrote: >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > I think this is everything (domain name >> changed to protect >> > > the >> > > > > > > guilty!): >> > > > > > > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > > > > > > >> > > > > > Hi Thomas, >> > > > > > >> > > > > > in the provided pastebin, the error 'certutil: >> function failed: >> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key >> database is in an >> > > old, >> > > > > > unsupported format' can be easily explained: >> there is a typo in >> > > the >> > > > > > directory path. >> > > > > > You can try with certutil -d >> /etc/pki/pki-tomcat/alias -L -n >> > > > > <nickname> >> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). >> > > > > > >> > > > > > You mention that the cert signing cert is >> expired, can you >> > > clarify >> > > > > > which >> > > > > > certificate this is? Please provide the subject >> name, certificate >> > > > > > nickname and location. >> > > > > > >> > > > > > Flo >> > > > > > > I pulled the same on the replica, which >> appears to be >> > > playing >> > > > > > up too >> > > > > > > in a similar fashion. >> > > > > > > >> > > > > > > I did just notice the date on the replica >> is out, I never >> > > set >> > > > > it >> > > > > > > back when I was trying to get the cert to >> renew. >> > > > > > > >> > > > > > > Let me know if you need anything else. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser >> Tweedale >> > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>> >> > > > > wrote: >> > > > > > > >> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM >> -0700, Thomas >> > > Letherby >> > > > > via >> > > > > > > FreeIPA-users wrote: >> > > > > > > > Hello all, >> > > > > > > > I had an issue a short while ago >> with a replica >> > > which >> > > > > > turned >> > > > > > > out to be an >> > > > > > > > expired certificate which I renewed >> and all seemed >> > > good. >> > > > > > > > >> > > > > > > > Seemed... >> > > > > > > > >> > > > > > > > It now appears that although the >> certificate >> > > renewed as >> > > > > > seen >> > > > > > > by getcert >> > > > > > > > -list, it didn't update >> /etc/httpd/alias and so the >> > > > > > httpd and >> > > > > > > tomcat-pki >> > > > > > > > services won't start unless I set >> the date to >> > > before the >> > > > > > > certificate >> > > > > > > > expired, and even then sometimes >> the httpd error_log >> > > > > shows: >> > > > > > > > Unable to verify certificate >> 'Server-Cert'. Add >> > > > > > > "NSSEnforceValidCerts off" >> > > > > > > > to nss.conf so the server can start >> until the >> > > problem >> > > > > > can be >> > > > > > > resolved. >> > > > > > > > and the service fails to start. >> > > > > > > > >> > > > > > > Hi Thomas, >> > > > > > > >> > > > > > > Can you please show `getcert list` >> output on the >> > > server in >> > > > > > question, >> > > > > > > as well as the output of >> > > > > > > >> > > > > > > certutil -d /etc/httpd/alias -L >> Server-Cert >> > > > > > > >> > > > > > > and >> > > > > > > >> > > > > > > certutil -d >> /etc/pki/pki-tomcatd/alias -L >> > > <nickname> >> > > > > > > >> > > > > > > for each nickname in the >> /etc/pki/pki-tomcatd/alias >> > > NSSDB. >> > > > > > > >> > > > > > > And Certmonger journal output. And >> pki debug log >> > > > > > > /var/log/pki/pki-tomcat/ca/debug. >> > > > > > > >> > > > > > > It is strange that `getcert list' >> shows an up to date >> > > > > > certificate >> > > > > > > while the actual certificate that is >> being tracked is >> > > > > > expired... >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Fraser >> > > > > > > >> > > > > > > > I've tried resubmitting the >> certificate, and it >> > > doesn't >> > > > > > seem >> > > > > > > to throw an >> > > > > > > > error, but it doesn't update /alias >> either. >> > > > > > > > Trying to access the server via the >> web page shows >> > > the >> > > > > old >> > > > > > > certificate >> > > > > > > > still in use. >> > > > > > > > I see the same certificate error >> with the replica >> > > > > server, >> > > > > > > which was freshly >> > > > > > > > rebuilt and added last week. >> > > > > > > > I've doubtless dug further into the >> hole trying to >> > > > > > > troubleshoot this, so I >> > > > > > > > probably need to start from the >> beginning again, >> > > and a >> > > > > > > pointer in the right >> > > > > > > > direction would be a great help! >> > > > > > > > >> > > > > > > > A getcert list shows all the >> certificates expiry >> > > dates >> > > > > well >> > > > > > > into the future. >> > > > > > > > >> > > > > > > > How can I get the certs back in >> sync? I've found a >> > > few >> > > > > > guides >> > > > > > > and most seem >> > > > > > > > to be for earlier versions, and I'm >> not sure if >> > > they're >> > > > > > still >> > > > > > > current. >> > > > > > > > >> > > > > > > > I can post whatever logs you think >> will help, I'm >> > > > > > afraid I'm >> > > > > > > not familiar >> > > > > > > > enough with them all to tell which >> are the most >> > > > > > relevant. Is >> > > > > > > there a guide >> > > > > > > > for the logs? >> > > > > > > > >> > > > > > > > Thanks for any help you can give, >> > > > > > > > >> > > > > > > > Thomas >> > > > > > > >> > > > > > > > >> _______________________________________________ >> > > > > > > > FreeIPA-users mailing list -- >> > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > > > > > > > To unsubscribe send an email to >> > > > > > > >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> >> > > > > > > > Fedora Code of Conduct: >> > > > > > > https://getfedora.org/code-of-conduct.html >> > > > > > > > List Guidelines: >> > > > > > > >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> > > > > > > > List Archives: >> > > > > > > >> > > > > > >> > > > > >> > >> > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > FreeIPA-users mailing list -- >> > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > To unsubscribe send an email to >> > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > Fedora Code of Conduct: >> > > https://getfedora.org/code-of-conduct.html >> > > > > > > List Guidelines: >> > > > > > >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> > > > > > > List Archives: >> > > > > > >> > > > > >> > >> > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/ >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > _______________________________________________ >> > > > > > FreeIPA-users mailing list >> -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > To unsubscribe send an email to >> > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > Fedora Code of >> Conduct: https://getfedora.org/code-of-conduct.html >> > > > > > List Guidelines: >> > > https://fedoraproject.org/wiki/Mailing_list_guidelines >> > > > > > List Archives: >> > > > > >> > >> > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/ >> > > > > > >> > > > > >> > > > > >> > > >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> To unsubscribe send an email to >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List >> Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Z2CWAOM4HBHXWBCQRFJXFCHMOEBRFPPO/ >
Hello Brian,
No problem, I don't expect a SLA on a free mailing list! If it was mission critical I'd have thrown a wedge of cash at Red Hat a long time ago...
I do appreciate any help though, some of the documentation is a little sketchy in places, when my kids grow up a bit and I have time again perhaps I can help out there.
I ran the first command three times, then the second. The ipa-update threw the following error:
trying https://xipa1.i.domain.net/ipa/json [try 1]: Forwarding 'schema' to json server ' https://xipa1.i.domain.net/ipa/json' cannot connect to 'https://xipa1.i.domain.net/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) The ipa-certupdate command failed.
It now shows the following, with the O=Domain cert being in date: certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=DOMAIN,ST=Arizona,C=US CT,C,C
And the pki-tomcatd service fails to restart with the following error:
Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48).
Thanks again,
Thomas
On Mon, Jul 23, 2018 at 8:10 PM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it should have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
You almost NEVER want to run this command. This renews the CA certificate. Nothing else. There is really no point. It is good for another 20 years.
Is this correct? If I have to there's not many certificates issued, and replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy to try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's not going to be the end of the world.
I'm sorry. I've had your paste open for a week now and keep forgetting to respond :-(
So you somehow have a bogus CA entry, serial # 4097. I'm not sure where that came from, I assume some self-signed CA of yours. The issuer is O=DOMAIN,ST=Arizona,C=US. It needs to go.
Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You can never be too careful.
What I'd recommend is to delete all the CA certs using certutil -D -d /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three times.
Then run ipa-certupdate. This should refresh the list with the proper CAs. certutil -L to show them again. There should be only one. If Apache is working you can use that cert database, /etc/httpd/alias, for comparison purposes.
For extra points you can verify it without starting the service:
# certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f /etc/dirsrv/slapd-INSTANCE/pwdfile.txt
So you have an existing Server-Cert but I can't really be sure which CA signed it. The above will tell you if it is currently trusted. It is good for another 2 years.
rob
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Here's the full listing from slap-d and pki-tomcat: https://pastebin.com/vWf2WVkN Is there any other logs that could help right now? And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this! Thomas On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> wrote: Thomas Letherby wrote: > Well, after poking around with the dates and a few restarts of services, > IPA now starts seemingly cleanly at the current date, although
the
> clients still don't seem to want to trust the CA, and I'm still seeing > the old cert crop up. > > If I look at the cert that wasn't updating before, it now
seems to
> contain three certs, the expired one and two new with much longer expiry > dates. > > [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET> IPA CA" | grep Not > Not Before: Sun Jun 17 09:06:38 2018 > Not After : Thu Jun 17 09:06:38 2038 > Not Before: Sun Jun 17 07:24:26 2018 > Not After : Thu Jun 17 07:24:26 2038 > Not Before: Thu Jun 08 06:51:04 2017 > Not After : Mon Jun 18 06:51:04 2018 > > Is this correct, or has it not updated the certificate correctly, if so, > how do I clean it up? This is rather confusing output. I think we need to see the full certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point? rob > > Thanks, > > Thomas > > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS > <christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu> <mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>>> wrote: > > From that I know you could trigger a refresh by restarting certmonger. > >> On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users >> <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> >> Hello Fraser, >> >> As I've been playing around with this before I dig in further I >> pulled the expiry for the certificates across all the places I >> know to look, if I have a cert listed, it's expired: >> >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> certutil -d /etc/httpd/alias -L >> Signing-Cert >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> getcert-list all up to date. >> >> ipa-getcert list all up to date >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> <http://i.domain.net/> IPA >> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" >> Expired >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate >> 1 - Expired >> 2 - Expired >> 3 - In date >> >> I've managed to narrow down the expiries to a crossover of one >> day, and setting the date to that day allows Tomcat-PKI to start, >> but the above results show that the certs haven't updated yet, but >> they may do in the next few hours? >> >> Thomas >> >> >> >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
>> >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: >> > Hello Fraser, >> > >> > The serial numbers appear to match, but if I run >> ipa-certupdate I get the >> > following: >> > >> > ipa-certupdate >> > trying https://server1.i.domain.net/ipa/json >> > Connection to https://server1.i.domain.net/ipa/json failed >> with [SSL: >> > CERTIFICATE_VERIFY_FAILED] certificate verify failed >> (_ssl.c:579) >> > >> > Tomcat is the only service that appears to be failing with >> the following >> > error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-8181) >> > Peer's Certificate has expired. (-1) >> > >> > But it should now be valid as I set the date back. If I set >> the date to >> > today I get this error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-12195) >> > Peer does not recognize and trust the CA that issued your >> certificate. (-1) >> > >> > Looks like it can't load because the certificate it uses >> isn't valid, if I >> > roll the clock back so the CA cert is, the
certificate
>> Tomcat is using >> > isn't valid and if I roll forward the CA cert isn't. >> > >> > How can I break this catch 22? >> > >> Which is the not-yet-valid certificate at the time to which you >> rolled back? The subsystemCert or the 389DS server certificate? >> >> In either case, you can look in the Dogtag certificate repository >> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the >> certificate that is valid at the relevant time. Copy the cert >> data >> (you can base64-decode the value to get the binary DER certificate >> data). Then you can delete the not-yet-valid-at-that-time >> certificate from the NSSDB and add the appropriate certificate >> using >> >> certutil -d <nssdb-path> -A -i <cert-path> >> >> If the certificate in question is the Dogtag subsystemCert, >> you will >> furthermore need to fix up the data in the uid=pkidbuser entry to >> match the "current" certificate. >> >> HTH, >> Fraser >> >> >> > Thanks, >> > >> > Thomas >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > wrote: >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby >> wrote: >> > > > Hello all, >> > > > >> > > > Here's the info: >> > > > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L >> > > > >> > > > Certificate Nickname >> Trust >> > > > Attributes >> > > > >> > > > SSL,S/MIME,JAR/XPI >> > > > >> > > > Server-Cert >> u,u,u >> > > > O=domain,ST=Arizona,C=US >> CT,C,C >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA >> CT,C,C >> > > > >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA is out of >> date for those. >> > > > >> > > Try running ipa-certupdate. It will update the IPA CA >> certificate >> > > in the various trust stores including the DS
NSSDB.
>> > > >> > > It reads the certificates from >> > > >> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > > >> > > so you should probably check that the certificate in that >> entry is >> > > up to date also. >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> > > -a >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > > > Matches >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > > > uid=pkidbuser,ou=people,o=ipaca
"(objectclass=*)"
>> usercertificate >> > > > >> > > > Thomas >> > > > >> > > > >> > > > >> > > > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden >> <rcritten@redhat.com <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >> > > wrote: >> > > > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > > > > > Hello Florence, >> > > > > > >> > > > > > It was the Signing-Cert and the I.domain.NET <http://I.domain.NET> >> <http://i.domain.net/> <http://I.domain.NET >> <http://i.domain.net/>> >> > > IPA >> > > > > > CA cert. By setting the clock back I managed to get >> those to renew, >> > > now >> > > > > > it seems I just need to get tomcat-pki to start. >> > > > > > >> > > > > > The error is: >> > > > > > >> > > > > > Internal Database Error encountered: Could
not
>> connect to LDAP server >> > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> <http://xipa1.i.xrs444.net/> <
>> <http://xipa1.i.xrs444.net/>> port 636 Error >> > > > > > netscape.ldap.LDAPException: Unable to create socket: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> SSL_ForceHandshake failed: >> > > > > > (-12195) Peer does not recognize and trust the CA >> that issued your >> > > > > > certificate. (-1) >> > > > > > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > > > > > >> > > > > > Certificate Nickname >> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Server-Cert cert-pki-ca >> u,u,u >> > > > > > ocspSigningCert cert-pki-ca >> u,u,u >> > > > > > O=domain,ST=Arizona,C=US >> CT,C,C >> > > > > > auditSigningCert cert-pki-ca >> u,u,Pu >> > > > > > subsystemCert cert-pki-ca >> u,u,u >> > > > > > caSigningCert cert-pki-ca >> > > CTu,Cu,Cu >> > > > > > >> > > > > > These are all set to expire in 2020 or
beyond.
>> > > > > > >> > > > > > certutil -d /etc/httpd/alias -L Server-Cert >> > > > > > >> > > > > > Certificate Nickname >> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Signing-Cert >> u,u,u >> > > > > > O=xrs444,ST=Arizona,C=US >> CT,C,C >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA >> > > > > > CT,C,C >> > > > > > Server-Cert >> u,u,u >> > > > > > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA and Signing-Cert are
the
>> > > > > > expired certs here. >> > > > > >> > > > > Don't worry about Signing-Cert. It is the cert used to >> sign the jar >> > > file >> > > > > used to autoconfigure Firefox. You should never need >> to re-sign one >> > > > > again (and this method isn't allowed in modern Firefox >> anyway). >> > > > > >> > > > > rob >> > > > > >> > > > > > >> > > > > > Thomas >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud < >> > > flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>> >> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>>>> wrote: >> > > > > > >> > > > > > On 06/27/2018 07:02 AM, Thomas Letherby
via
>> FreeIPA-users wrote: >> > > > > > > After some fiddling with dates some more I >> seem to have the >> > > HTTPD >> > > > > > cert >> > > > > > > in sync, however it appears the cert signing >> cert is expired. >> > > > > > > >> > > > > > > named also says it's starting, but doesn't >> seem to want to >> > > respond. >> > > > > > > >> > > > > > > I don't have time to dig into it more tonight, >> but let me know >> > > what >> > > > > > > other information or tests I can run and I'll >> get them posted >> > > > > > tomorrow. >> > > > > > > >> > > > > > > Thanks all. >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < >> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> >> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net
>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>>> wrote: >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > I think this is everything (domain name >> changed to protect >> > > the >> > > > > > > guilty!): >> > > > > > > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > > > > > > >> > > > > > Hi Thomas, >> > > > > > >> > > > > > in the provided pastebin, the error 'certutil: >> function failed: >> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key >> database is in an >> > > old, >> > > > > > unsupported format' can be easily explained: >> there is a typo in >> > > the >> > > > > > directory path. >> > > > > > You can try with certutil -d >> /etc/pki/pki-tomcat/alias -L -n >> > > > > <nickname> >> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). >> > > > > > >> > > > > > You mention that the cert signing cert
is
>> expired, can you >> > > clarify >> > > > > > which >> > > > > > certificate this is? Please provide the subject >> name, certificate >> > > > > > nickname and location. >> > > > > > >> > > > > > Flo >> > > > > > > I pulled the same on the replica, which >> appears to be >> > > playing >> > > > > > up too >> > > > > > > in a similar fashion. >> > > > > > > >> > > > > > > I did just notice the date on the replica >> is out, I never >> > > set >> > > > > it >> > > > > > > back when I was trying to get the cert to >> renew. >> > > > > > > >> > > > > > > Let me know if you need anything else. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser >> Tweedale >> > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>> >> > > > > wrote: >> > > > > > > >> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM >> -0700, Thomas >> > > Letherby >> > > > > via >> > > > > > > FreeIPA-users wrote: >> > > > > > > > Hello all, >> > > > > > > > I had an issue a short while ago >> with a replica >> > > which >> > > > > > turned >> > > > > > > out to be an >> > > > > > > > expired certificate which I renewed >> and all seemed >> > > good. >> > > > > > > > >> > > > > > > > Seemed... >> > > > > > > > >> > > > > > > > It now appears that although the >> certificate >> > > renewed as >> > > > > > seen >> > > > > > > by getcert >> > > > > > > > -list, it didn't update >> /etc/httpd/alias and so the >> > > > > > httpd and >> > > > > > > tomcat-pki >> > > > > > > > services won't start unless I set >> the date to >> > > before the >> > > > > > > certificate >> > > > > > > > expired, and even then sometimes >> the httpd error_log >> > > > > shows: >> > > > > > > > Unable to verify
certificate
>> 'Server-Cert'. Add >> > > > > > > "NSSEnforceValidCerts off" >> > > > > > > > to nss.conf so the server can start >> until the >> > > problem >> > > > > > can be >> > > > > > > resolved. >> > > > > > > > and the service fails to start. >> > > > > > > > >> > > > > > > Hi Thomas, >> > > > > > > >> > > > > > > Can you please show `getcert list` >> output on the >> > > server in >> > > > > > question, >> > > > > > > as well as the output of >> > > > > > > >> > > > > > > certutil -d /etc/httpd/alias -L >> Server-Cert >> > > > > > > >> > > > > > > and >> > > > > > > >> > > > > > > certutil -d >> /etc/pki/pki-tomcatd/alias -L >> > > <nickname> >> > > > > > > >> > > > > > > for each nickname in the >> /etc/pki/pki-tomcatd/alias >> > > NSSDB. >> > > > > > > >> > > > > > > And Certmonger journal output. And >> pki debug log >> > > > > > >
/var/log/pki/pki-tomcat/ca/debug.
>> > > > > > > >> > > > > > > It is strange that `getcert
list'
>> shows an up to date >> > > > > > certificate >> > > > > > > while the actual certificate that is >> being tracked is >> > > > > > expired... >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Fraser >> > > > > > > >> > > > > > > > I've tried resubmitting the >> certificate, and it >> > > doesn't >> > > > > > seem >> > > > > > > to throw an >> > > > > > > > error, but it doesn't update /alias >> either. >> > > > > > > > Trying to access the server via the >> web page shows >> > > the >> > > > > old >> > > > > > > certificate >> > > > > > > > still in use. >> > > > > > > > I see the same certificate error >> with the replica >> > > > > server, >> > > > > > > which was freshly >> > > > > > > > rebuilt and added last
week.
>> > > > > > > > I've doubtless dug further into the >> hole trying to >> > > > > > > troubleshoot this, so I >> > > > > > > > probably need to start from the >> beginning again, >> > > and a >> > > > > > > pointer in the right >> > > > > > > > direction would be a great help! >> > > > > > > > >> > > > > > > > A getcert list shows all
the
>> certificates expiry >> > > dates >> > > > > well >> > > > > > > into the future. >> > > > > > > > >> > > > > > > > How can I get the certs back in >> sync? I've found a >> > > few >> > > > > > guides >> > > > > > > and most seem >> > > > > > > > to be for earlier versions, and I'm >> not sure if >> > > they're >> > > > > > still >> > > > > > > current. >> > > > > > > > >> > > > > > > > I can post whatever logs you think >> will help, I'm >> > > > > > afraid I'm >> > > > > > > not familiar >> > > > > > > > enough with them all to tell which >> are the most >> > > > > > relevant. Is >> > > > > > > there a guide >> > > > > > > > for the logs? >> > > > > > > > >> > > > > > > > Thanks for any help you can give, >> > > > > > > > >> > > > > > > > Thomas >> > > > > > > >> > > > > > > > >> _______________________________________________ >> > > > > > > > FreeIPA-users mailing list
--
>> > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > > > > > > > To unsubscribe send an email to >> > > > > > > >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> >> > > > > > > > Fedora Code of Conduct: >> > > > > > > https://getfedora.org/code-of-conduct.html >> > > > > > > > List Guidelines: >> > > > > > > >>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > > List Archives: >> > > > > > > >> > > > > > >> > > > > >> > >> >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > FreeIPA-users mailing list -- >> > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > To unsubscribe send an email to >> > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > >
I think I'm stuck in a bit of a catch 22 here, I can't update the cert because the cert it's replacing is bad. Is there a way to force it to ignore the existing cert when it goes to update?
Thomas
On Mon, Jul 23, 2018 at 8:59 PM Thomas Letherby xrs444@xrs444.net wrote:
Hello Brian,
No problem, I don't expect a SLA on a free mailing list! If it was mission critical I'd have thrown a wedge of cash at Red Hat a long time ago...
I do appreciate any help though, some of the documentation is a little sketchy in places, when my kids grow up a bit and I have time again perhaps I can help out there.
I ran the first command three times, then the second. The ipa-update threw the following error:
trying https://xipa1.i.domain.net/ipa/json [try 1]: Forwarding 'schema' to json server ' https://xipa1.i.domain.net/ipa/json' cannot connect to 'https://xipa1.i.domain.net/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) The ipa-certupdate command failed.
It now shows the following, with the O=Domain cert being in date: certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=DOMAIN,ST=Arizona,C=US CT,C,C
And the pki-tomcatd service fails to restart with the following error:
Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48).
Thanks again,
Thomas
On Mon, Jul 23, 2018 at 8:10 PM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it
should
have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
You almost NEVER want to run this command. This renews the CA certificate. Nothing else. There is really no point. It is good for another 20 years.
Is this correct? If I have to there's not many certificates issued, and replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy to try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's not going to be the end of the world.
I'm sorry. I've had your paste open for a week now and keep forgetting to respond :-(
So you somehow have a bogus CA entry, serial # 4097. I'm not sure where that came from, I assume some self-signed CA of yours. The issuer is O=DOMAIN,ST=Arizona,C=US. It needs to go.
Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You can never be too careful.
What I'd recommend is to delete all the CA certs using certutil -D -d /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three times.
Then run ipa-certupdate. This should refresh the list with the proper CAs. certutil -L to show them again. There should be only one. If Apache is working you can use that cert database, /etc/httpd/alias, for comparison purposes.
For extra points you can verify it without starting the service:
# certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f /etc/dirsrv/slapd-INSTANCE/pwdfile.txt
So you have an existing Server-Cert but I can't really be sure which CA signed it. The above will tell you if it is currently trusted. It is good for another 2 years.
rob
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Here's the full listing from slap-d and pki-tomcat: https://pastebin.com/vWf2WVkN Is there any other logs that could help right now? And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this! Thomas On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <
rcritten@redhat.com
<mailto:rcritten@redhat.com>> wrote: Thomas Letherby wrote: > Well, after poking around with the dates and a few restarts of services, > IPA now starts seemingly cleanly at the current date,
although the
> clients still don't seem to want to trust the CA, and I'm still seeing > the old cert crop up. > > If I look at the cert that wasn't updating before, it now
seems to
> contain three certs, the expired one and two new with much longer expiry > dates. > > [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET> IPA CA" | grep Not > Not Before: Sun Jun 17 09:06:38 2018 > Not After : Thu Jun 17 09:06:38 2038 > Not Before: Sun Jun 17 07:24:26 2018 > Not After : Thu Jun 17 07:24:26 2038 > Not Before: Thu Jun 08 06:51:04 2017 > Not After : Mon Jun 18 06:51:04 2018 > > Is this correct, or has it not updated the certificate correctly, if so, > how do I clean it up? This is rather confusing output. I think we need to see the full certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point? rob > > Thanks, > > Thomas > > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS > <christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu> <mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>>> wrote: > > From that I know you could trigger a refresh by restarting certmonger. > >> On 9 Jul 2018, at 07:38, Thomas Letherby via
FreeIPA-users
>> <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> >> Hello Fraser, >> >> As I've been playing around with this before I dig in further I >> pulled the expiry for the certificates across all the places I >> know to look, if I have a cert listed, it's expired: >> >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> certutil -d /etc/httpd/alias -L >> Signing-Cert >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> getcert-list all up to date. >> >> ipa-getcert list all up to date >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> <http://i.domain.net/> IPA >> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" >> Expired >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate >> 1 - Expired >> 2 - Expired >> 3 - In date >> >> I've managed to narrow down the expiries to a crossover of one >> day, and setting the date to that day allows Tomcat-PKI to start, >> but the above results show that the certs haven't updated yet, but >> they may do in the next few hours? >> >> Thomas >> >> >> >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
>> >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: >> > Hello Fraser, >> > >> > The serial numbers appear to match, but if I run >> ipa-certupdate I get the >> > following: >> > >> > ipa-certupdate >> > trying https://server1.i.domain.net/ipa/json >> > Connection to https://server1.i.domain.net/ipa/json failed >> with [SSL: >> > CERTIFICATE_VERIFY_FAILED] certificate verify
failed
>> (_ssl.c:579) >> > >> > Tomcat is the only service that appears to be failing with >> the following >> > error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-8181) >> > Peer's Certificate has expired. (-1) >> > >> > But it should now be valid as I set the date back. If I set >> the date to >> > today I get this error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-12195) >> > Peer does not recognize and trust the CA that issued your >> certificate. (-1) >> > >> > Looks like it can't load because the certificate it uses >> isn't valid, if I >> > roll the clock back so the CA cert is, the
certificate
>> Tomcat is using >> > isn't valid and if I roll forward the CA cert
isn't.
>> > >> > How can I break this catch 22? >> > >> Which is the not-yet-valid certificate at the time to which you >> rolled back? The subsystemCert or the 389DS server certificate? >> >> In either case, you can look in the Dogtag certificate repository >> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the >> certificate that is valid at the relevant time. Copy the cert >> data >> (you can base64-decode the value to get the binary DER certificate >> data). Then you can delete the not-yet-valid-at-that-time >> certificate from the NSSDB and add the appropriate certificate >> using >> >> certutil -d <nssdb-path> -A -i <cert-path> >> >> If the certificate in question is the Dogtag subsystemCert, >> you will >> furthermore need to fix up the data in the uid=pkidbuser entry to >> match the "current" certificate. >> >> HTH, >> Fraser >> >> >> > Thanks, >> > >> > Thomas >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > wrote: >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby >> wrote: >> > > > Hello all, >> > > > >> > > > Here's the info: >> > > > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L >> > > > >> > > > Certificate Nickname >> Trust >> > > > Attributes >> > > > >> > > > SSL,S/MIME,JAR/XPI >> > > > >> > > > Server-Cert >> u,u,u >> > > > O=domain,ST=Arizona,C=US >> CT,C,C >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA >> CT,C,C >> > > > >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA is out of >> date for those. >> > > > >> > > Try running ipa-certupdate. It will update the IPA CA >> certificate >> > > in the various trust stores including the DS
NSSDB.
>> > > >> > > It reads the certificates from >> > > >> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > > >> > > so you should probably check that the certificate in that >> entry is >> > > up to date also. >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> > > -a >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > > > Matches >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > > > uid=pkidbuser,ou=people,o=ipaca
"(objectclass=*)"
>> usercertificate >> > > > >> > > > Thomas >> > > > >> > > > >> > > > >> > > > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden >> <rcritten@redhat.com <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >> > > wrote: >> > > > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > > > > > Hello Florence, >> > > > > > >> > > > > > It was the Signing-Cert and the I.domain.NET <http://I.domain.NET> >> <http://i.domain.net/> <http://I.domain.NET >> <http://i.domain.net/>> >> > > IPA >> > > > > > CA cert. By setting the clock back I managed to get >> those to renew, >> > > now >> > > > > > it seems I just need to get tomcat-pki to start. >> > > > > > >> > > > > > The error is: >> > > > > > >> > > > > > Internal Database Error encountered: Could
not
>> connect to LDAP server >> > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> <http://xipa1.i.xrs444.net/> <
>> <http://xipa1.i.xrs444.net/>> port 636 Error >> > > > > > netscape.ldap.LDAPException: Unable to create socket: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> SSL_ForceHandshake failed: >> > > > > > (-12195) Peer does not recognize and trust the CA >> that issued your >> > > > > > certificate. (-1) >> > > > > > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > > > > > >> > > > > > Certificate Nickname >> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Server-Cert cert-pki-ca >> u,u,u >> > > > > > ocspSigningCert cert-pki-ca >> u,u,u >> > > > > > O=domain,ST=Arizona,C=US >> CT,C,C >> > > > > > auditSigningCert cert-pki-ca >> u,u,Pu >> > > > > > subsystemCert cert-pki-ca >> u,u,u >> > > > > > caSigningCert cert-pki-ca >> > > CTu,Cu,Cu >> > > > > > >> > > > > > These are all set to expire in 2020 or
beyond.
>> > > > > > >> > > > > > certutil -d /etc/httpd/alias -L Server-Cert >> > > > > > >> > > > > > Certificate Nickname >> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Signing-Cert >> u,u,u >> > > > > > O=xrs444,ST=Arizona,C=US >> CT,C,C >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA >> > > > > > CT,C,C >> > > > > > Server-Cert >> u,u,u >> > > > > > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA and Signing-Cert are
the
>> > > > > > expired certs here. >> > > > > >> > > > > Don't worry about Signing-Cert. It is the cert used to >> sign the jar >> > > file >> > > > > used to autoconfigure Firefox. You should never need >> to re-sign one >> > > > > again (and this method isn't allowed in modern Firefox >> anyway). >> > > > > >> > > > > rob >> > > > > >> > > > > > >> > > > > > Thomas >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud < >> > > flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>> >> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>>>> wrote: >> > > > > > >> > > > > > On 06/27/2018 07:02 AM, Thomas
Letherby via
>> FreeIPA-users wrote: >> > > > > > > After some fiddling with dates some more I >> seem to have the >> > > HTTPD >> > > > > > cert >> > > > > > > in sync, however it appears the cert signing >> cert is expired. >> > > > > > > >> > > > > > > named also says it's starting, but doesn't >> seem to want to >> > > respond. >> > > > > > > >> > > > > > > I don't have time to dig into it more tonight, >> but let me know >> > > what >> > > > > > > other information or tests I can run and I'll >> get them posted >> > > > > > tomorrow. >> > > > > > > >> > > > > > > Thanks all. >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < >> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> >> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net
>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>>> wrote: >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > I think this is everything (domain name >> changed to protect >> > > the >> > > > > > > guilty!): >> > > > > > > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > > > > > > >> > > > > > Hi Thomas, >> > > > > > >> > > > > > in the provided pastebin, the error 'certutil: >> function failed: >> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key >> database is in an >> > > old, >> > > > > > unsupported format' can be easily explained: >> there is a typo in >> > > the >> > > > > > directory path. >> > > > > > You can try with certutil -d >> /etc/pki/pki-tomcat/alias -L -n >> > > > > <nickname> >> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). >> > > > > > >> > > > > > You mention that the cert signing cert
is
>> expired, can you >> > > clarify >> > > > > > which >> > > > > > certificate this is? Please provide the subject >> name, certificate >> > > > > > nickname and location. >> > > > > > >> > > > > > Flo >> > > > > > > I pulled the same on the replica, which >> appears to be >> > > playing >> > > > > > up too >> > > > > > > in a similar fashion. >> > > > > > > >> > > > > > > I did just notice the date on the replica >> is out, I never >> > > set >> > > > > it >> > > > > > > back when I was trying to get the cert to >> renew. >> > > > > > > >> > > > > > > Let me know if you need anything else. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser >> Tweedale >> > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>> >> > > > > wrote: >> > > > > > > >> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM >> -0700, Thomas >> > > Letherby >> > > > > via >> > > > > > > FreeIPA-users wrote: >> > > > > > > > Hello all, >> > > > > > > > I had an issue a short while ago >> with a replica >> > > which >> > > > > > turned >> > > > > > > out to be an >> > > > > > > > expired certificate which I renewed >> and all seemed >> > > good. >> > > > > > > > >> > > > > > > > Seemed... >> > > > > > > > >> > > > > > > > It now appears that although the >> certificate >> > > renewed as >> > > > > > seen >> > > > > > > by getcert >> > > > > > > > -list, it didn't update >> /etc/httpd/alias and so the >> > > > > > httpd and >> > > > > > > tomcat-pki >> > > > > > > > services won't start unless I set >> the date to >> > > before the >> > > > > > > certificate >> > > > > > > > expired, and even then sometimes >> the httpd error_log >> > > > > shows: >> > > > > > > > Unable to verify
certificate
>> 'Server-Cert'. Add >> > > > > > > "NSSEnforceValidCerts off" >> > > > > > > > to nss.conf so the server can start >> until the >> > > problem >> > > > > > can be >> > > > > > > resolved. >> > > > > > > > and the service fails to start. >> > > > > > > > >> > > > > > > Hi Thomas, >> > > > > > > >> > > > > > > Can you please show `getcert list` >> output on the >> > > server in >> > > > > > question, >> > > > > > > as well as the output of >> > > > > > > >> > > > > > > certutil -d /etc/httpd/alias -L >> Server-Cert >> > > > > > > >> > > > > > > and >> > > > > > > >> > > > > > > certutil -d >> /etc/pki/pki-tomcatd/alias -L >> > > <nickname> >> > > > > > > >> > > > > > > for each nickname in the >> /etc/pki/pki-tomcatd/alias >> > > NSSDB. >> > > > > > > >> > > > > > > And Certmonger journal output. And >> pki debug log >> > > > > > >
/var/log/pki/pki-tomcat/ca/debug.
>> > > > > > > >> > > > > > > It is strange that `getcert
list'
>> shows an up to date >> > > > > > certificate >> > > > > > > while the actual certificate that is >> being tracked is >> > > > > > expired... >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Fraser >> > > > > > > >> > > > > > > > I've tried resubmitting
the
>> certificate, and it >> > > doesn't >> > > > > > seem >> > > > > > > to throw an >> > > > > > > > error, but it doesn't update /alias >> either. >> > > > > > > > Trying to access the server via the >> web page shows >> > > the >> > > > > old >> > > > > > > certificate >> > > > > > > > still in use. >> > > > > > > > I see the same certificate error >> with the replica >> > > > > server, >> > > > > > > which was freshly >> > > > > > > > rebuilt and added last
week.
>> > > > > > > > I've doubtless dug further into the >> hole trying to >> > > > > > > troubleshoot this, so I >> > > > > > > > probably need to start from the >> beginning again, >> > > and a >> > > > > > > pointer in the right >> > > > > > > > direction would be a great help! >> > > > > > > > >> > > > > > > > A getcert list shows all
the
>> certificates expiry >> > > dates >> > > > > well >> > > > > > > into the future. >> > > > > > > > >> > > > > > > > How can I get the certs back in >> sync? I've found a >> > > few >> > > > > > guides >> > > > > > > and most seem >> > > > > > > > to be for earlier versions, and I'm >> not sure if >> > > they're >> > > > > > still >> > > > > > > current. >> > > > > > > > >> > > > > > > > I can post whatever logs you think >> will help, I'm >> > > > > > afraid I'm >> > > > > > > not familiar >> > > > > > > > enough with them all to tell which >> are the most >> > > > > > relevant. Is >> > > > > > > there a guide >> > > > > > > > for the logs? >> > > > > > > > >> > > > > > > > Thanks for any help you can give, >> > > > > > > > >> > > > > > > > Thomas >> > > > > > > >> > > > > > > > >> _______________________________________________ >> > > > > > > > FreeIPA-users mailing
list --
>> > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > > > > > > > To unsubscribe send an email to >> > > > > > > >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> >> > > > > > > > Fedora Code of Conduct: >> > > > > > > https://getfedora.org/code-of-conduct.html >> > > > > > > > List Guidelines: >> > > > > > > >>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > > List Archives: >> > > > > > > >> > > > > > >> > > > > >> > >> >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > FreeIPA-users mailing list -- >> > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > To unsubscribe send an email to >> > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > >
I tried using the instructions here, given that the server certs are out of step with the CA cert:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
But when I go to submit the request using certutil as per here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
I get this error:
ipa: ERROR: cannot connect to 'any of the configured servers'
This is probably because Tomcat is failing to start. I've set HTTPD to ignore cert errors, and it's set to WARN in LDAP.
The Tomcat error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
Seem to be playing chase the error here, but if I can get Tomcat to start, I should be able to replace the certificates and be back up and running.
Any idea how to do that?
Thanks all!
Thomas
On Wed, Aug 1, 2018 at 8:35 PM Thomas Letherby xrs444@xrs444.net wrote:
I think I'm stuck in a bit of a catch 22 here, I can't update the cert because the cert it's replacing is bad. Is there a way to force it to ignore the existing cert when it goes to update?
Thomas
On Mon, Jul 23, 2018 at 8:59 PM Thomas Letherby xrs444@xrs444.net wrote:
Hello Brian,
No problem, I don't expect a SLA on a free mailing list! If it was mission critical I'd have thrown a wedge of cash at Red Hat a long time ago...
I do appreciate any help though, some of the documentation is a little sketchy in places, when my kids grow up a bit and I have time again perhaps I can help out there.
I ran the first command three times, then the second. The ipa-update threw the following error:
trying https://xipa1.i.domain.net/ipa/json [try 1]: Forwarding 'schema' to json server ' https://xipa1.i.domain.net/ipa/json' cannot connect to 'https://xipa1.i.domain.net/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) The ipa-certupdate command failed.
It now shows the following, with the O=Domain cert being in date: certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=DOMAIN,ST=Arizona,C=US CT,C,C
And the pki-tomcatd service fails to restart with the following error:
Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48).
Thanks again,
Thomas
On Mon, Jul 23, 2018 at 8:10 PM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it
should
have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
You almost NEVER want to run this command. This renews the CA certificate. Nothing else. There is really no point. It is good for another 20 years.
Is this correct? If I have to there's not many certificates issued, and replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy to try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's not going to be the end of the world.
I'm sorry. I've had your paste open for a week now and keep forgetting to respond :-(
So you somehow have a bogus CA entry, serial # 4097. I'm not sure where that came from, I assume some self-signed CA of yours. The issuer is O=DOMAIN,ST=Arizona,C=US. It needs to go.
Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You can never be too careful.
What I'd recommend is to delete all the CA certs using certutil -D -d /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three times.
Then run ipa-certupdate. This should refresh the list with the proper CAs. certutil -L to show them again. There should be only one. If Apache is working you can use that cert database, /etc/httpd/alias, for comparison purposes.
For extra points you can verify it without starting the service:
# certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f /etc/dirsrv/slapd-INSTANCE/pwdfile.txt
So you have an existing Server-Cert but I can't really be sure which CA signed it. The above will tell you if it is currently trusted. It is good for another 2 years.
rob
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Here's the full listing from slap-d and pki-tomcat: https://pastebin.com/vWf2WVkN Is there any other logs that could help right now? And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this! Thomas On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <
rcritten@redhat.com
<mailto:rcritten@redhat.com>> wrote: Thomas Letherby wrote: > Well, after poking around with the dates and a few restarts
of
services, > IPA now starts seemingly cleanly at the current date,
although the
> clients still don't seem to want to trust the CA, and I'm still seeing > the old cert crop up. > > If I look at the cert that wasn't updating before, it now
seems to
> contain three certs, the expired one and two new with much longer expiry > dates. > > [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET>
IPA
CA" | grep Not > Not Before: Sun Jun 17 09:06:38 2018 > Not After : Thu Jun 17 09:06:38 2038 > Not Before: Sun Jun 17 07:24:26 2018 > Not After : Thu Jun 17 07:24:26 2038 > Not Before: Thu Jun 08 06:51:04 2017 > Not After : Mon Jun 18 06:51:04 2018 > > Is this correct, or has it not updated the certificate correctly, if so, > how do I clean it up? This is rather confusing output. I think we need to see the
full
certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point? rob > > Thanks, > > Thomas > > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS > <christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>>> wrote: > > From that I know you could trigger a refresh by
restarting
certmonger. > >> On 9 Jul 2018, at 07:38, Thomas Letherby via
FreeIPA-users
>> <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> >> Hello Fraser, >> >> As I've been playing around with this before I dig in further I >> pulled the expiry for the certificates across all the places I >> know to look, if I have a cert listed, it's expired: >> >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> certutil -d /etc/httpd/alias -L >> Signing-Cert >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> getcert-list all up to date. >> >> ipa-getcert list all up to date >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> <http://i.domain.net/> IPA >> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" >> Expired >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate >> 1 - Expired >> 2 - Expired >> 3 - In date >> >> I've managed to narrow down the expiries to a crossover of one >> day, and setting the date to that day allows Tomcat-PKI to start, >> but the above results show that the certs haven't
updated
yet, but >> they may do in the next few hours? >> >> Thomas >> >> >> >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
>> >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: >> > Hello Fraser, >> > >> > The serial numbers appear to match, but if I run >> ipa-certupdate I get the >> > following: >> > >> > ipa-certupdate >> > trying https://server1.i.domain.net/ipa/json >> > Connection to https://server1.i.domain.net/ipa/json failed >> with [SSL: >> > CERTIFICATE_VERIFY_FAILED] certificate verify
failed
>> (_ssl.c:579) >> > >> > Tomcat is the only service that appears to be failing with >> the following >> > error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-8181) >> > Peer's Certificate has expired. (-1) >> > >> > But it should now be valid as I set the date back. If I set >> the date to >> > today I get this error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-12195) >> > Peer does not recognize and trust the CA that issued your >> certificate. (-1) >> > >> > Looks like it can't load because the certificate
it
uses >> isn't valid, if I >> > roll the clock back so the CA cert is, the
certificate
>> Tomcat is using >> > isn't valid and if I roll forward the CA cert
isn't.
>> > >> > How can I break this catch 22? >> > >> Which is the not-yet-valid certificate at the time
to
which you >> rolled back? The subsystemCert or the 389DS server certificate? >> >> In either case, you can look in the Dogtag certificate repository >> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the >> certificate that is valid at the relevant time.
Copy
the cert >> data >> (you can base64-decode the value to get the binary DER certificate >> data). Then you can delete the not-yet-valid-at-that-time >> certificate from the NSSDB and add the appropriate certificate >> using >> >> certutil -d <nssdb-path> -A -i <cert-path> >> >> If the certificate in question is the Dogtag subsystemCert, >> you will >> furthermore need to fix up the data in the uid=pkidbuser entry to >> match the "current" certificate. >> >> HTH, >> Fraser >> >> >> > Thanks, >> > >> > Thomas >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > wrote: >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby >> wrote: >> > > > Hello all, >> > > > >> > > > Here's the info: >> > > > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L >> > > > >> > > > Certificate Nickname
>> Trust >> > > > Attributes >> > > > >> > > > SSL,S/MIME,JAR/XPI >> > > > >> > > > Server-Cert >> u,u,u >> > > > O=domain,ST=Arizona,C=US
>> CT,C,C >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA >> CT,C,C >> > > > >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA is out of >> date for those. >> > > > >> > > Try running ipa-certupdate. It will update the IPA CA >> certificate >> > > in the various trust stores including the DS
NSSDB.
>> > > >> > > It reads the certificates from >> > > >> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > > >> > > so you should probably check that the
certificate
in that >> entry is >> > > up to date also. >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> > > -a >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > > > Matches >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > > > uid=pkidbuser,ou=people,o=ipaca
"(objectclass=*)"
>> usercertificate >> > > > >> > > > Thomas >> > > > >> > > > >> > > > >> > > > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden >> <rcritten@redhat.com <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >> > > wrote: >> > > > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > > > > > Hello Florence, >> > > > > > >> > > > > > It was the Signing-Cert and the I.domain.NET <http://I.domain.NET> >> <http://i.domain.net/> <http://I.domain.NET >> <http://i.domain.net/>> >> > > IPA >> > > > > > CA cert. By setting the clock back I managed to get >> those to renew, >> > > now >> > > > > > it seems I just need to get tomcat-pki to start. >> > > > > > >> > > > > > The error is: >> > > > > > >> > > > > > Internal Database Error encountered:
Could not
>> connect to LDAP server >> > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> <http://xipa1.i.xrs444.net/> <
>> <http://xipa1.i.xrs444.net/>> port 636 Error >> > > > > > netscape.ldap.LDAPException: Unable to create socket: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> SSL_ForceHandshake failed: >> > > > > > (-12195) Peer does not recognize and trust the CA >> that issued your >> > > > > > certificate. (-1) >> > > > > > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > > > > > >> > > > > > Certificate Nickname
>> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Server-Cert cert-pki-ca >> u,u,u >> > > > > > ocspSigningCert cert-pki-ca >> u,u,u >> > > > > > O=domain,ST=Arizona,C=US
>> CT,C,C >> > > > > > auditSigningCert cert-pki-ca
>> u,u,Pu >> > > > > > subsystemCert cert-pki-ca >> u,u,u >> > > > > > caSigningCert cert-pki-ca >> > > CTu,Cu,Cu >> > > > > > >> > > > > > These are all set to expire in 2020 or
beyond.
>> > > > > > >> > > > > > certutil -d /etc/httpd/alias -L
Server-Cert
>> > > > > > >> > > > > > Certificate Nickname
>> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Signing-Cert
>> u,u,u >> > > > > > O=xrs444,ST=Arizona,C=US
>> CT,C,C >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA >> > > > > > CT,C,C >> > > > > > Server-Cert >> u,u,u >> > > > > > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA and Signing-Cert
are the
>> > > > > > expired certs here. >> > > > > >> > > > > Don't worry about Signing-Cert. It is the cert used to >> sign the jar >> > > file >> > > > > used to autoconfigure Firefox. You should never need >> to re-sign one >> > > > > again (and this method isn't allowed in modern Firefox >> anyway). >> > > > > >> > > > > rob >> > > > > >> > > > > > >> > > > > > Thomas >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud < >> > > flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>> >> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>>>> wrote: >> > > > > > >> > > > > > On 06/27/2018 07:02 AM, Thomas
Letherby via
>> FreeIPA-users wrote: >> > > > > > > After some fiddling with dates some more I >> seem to have the >> > > HTTPD >> > > > > > cert >> > > > > > > in sync, however it appears the cert signing >> cert is expired. >> > > > > > > >> > > > > > > named also says it's starting, but doesn't >> seem to want to >> > > respond. >> > > > > > > >> > > > > > > I don't have time to dig into it
more
tonight, >> but let me know >> > > what >> > > > > > > other information or tests I can run and I'll >> get them posted >> > > > > > tomorrow. >> > > > > > > >> > > > > > > Thanks all. >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < >> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> >> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net
>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>>> wrote: >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > I think this is everything (domain name >> changed to protect >> > > the >> > > > > > > guilty!): >> > > > > > > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > > > > > > >> > > > > > Hi Thomas, >> > > > > > >> > > > > > in the provided pastebin, the error 'certutil: >> function failed: >> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key >> database is in an >> > > old, >> > > > > > unsupported format' can be easily explained: >> there is a typo in >> > > the >> > > > > > directory path. >> > > > > > You can try with certutil -d >> /etc/pki/pki-tomcat/alias -L -n >> > > > > <nickname> >> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). >> > > > > > >> > > > > > You mention that the cert signing
cert is
>> expired, can you >> > > clarify >> > > > > > which >> > > > > > certificate this is? Please provide
the
subject >> name, certificate >> > > > > > nickname and location. >> > > > > > >> > > > > > Flo >> > > > > > > I pulled the same on the
replica,
which >> appears to be >> > > playing >> > > > > > up too >> > > > > > > in a similar fashion. >> > > > > > > >> > > > > > > I did just notice the date on
the
replica >> is out, I never >> > > set >> > > > > it >> > > > > > > back when I was trying to get
the
cert to >> renew. >> > > > > > > >> > > > > > > Let me know if you need anything else. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser >> Tweedale >> > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>> >> > > > > wrote: >> > > > > > > >> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM >> -0700, Thomas >> > > Letherby >> > > > > via >> > > > > > > FreeIPA-users wrote: >> > > > > > > > Hello all, >> > > > > > > > I had an issue a short while ago >> with a replica >> > > which >> > > > > > turned >> > > > > > > out to be an >> > > > > > > > expired certificate which I renewed >> and all seemed >> > > good. >> > > > > > > > >> > > > > > > > Seemed... >> > > > > > > > >> > > > > > > > It now appears that although the >> certificate >> > > renewed as >> > > > > > seen >> > > > > > > by getcert >> > > > > > > > -list, it didn't update >> /etc/httpd/alias and so the >> > > > > > httpd and >> > > > > > > tomcat-pki >> > > > > > > > services won't start unless I set >> the date to >> > > before the >> > > > > > > certificate >> > > > > > > > expired, and even then sometimes >> the httpd error_log >> > > > > shows: >> > > > > > > > Unable to verify
certificate
>> 'Server-Cert'. Add >> > > > > > > "NSSEnforceValidCerts off" >> > > > > > > > to nss.conf so the server can start >> until the >> > > problem >> > > > > > can be >> > > > > > > resolved. >> > > > > > > > and the service fails to start. >> > > > > > > > >> > > > > > > Hi Thomas, >> > > > > > > >> > > > > > > Can you please show `getcert list` >> output on the >> > > server in >> > > > > > question, >> > > > > > > as well as the output of >> > > > > > > >> > > > > > > certutil -d /etc/httpd/alias -L >> Server-Cert >> > > > > > > >> > > > > > > and >> > > > > > > >> > > > > > > certutil -d >> /etc/pki/pki-tomcatd/alias -L >> > > <nickname> >> > > > > > > >> > > > > > > for each nickname in the >> /etc/pki/pki-tomcatd/alias >> > > NSSDB. >> > > > > > > >> > > > > > > And Certmonger journal output. And >> pki debug log >> > > > > > >
/var/log/pki/pki-tomcat/ca/debug.
>> > > > > > > >> > > > > > > It is strange that `getcert
list'
>> shows an up to date >> > > > > > certificate >> > > > > > > while the actual certificate that is >> being tracked is >> > > > > > expired... >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Fraser >> > > > > > > >> > > > > > > > I've tried resubmitting
the
>> certificate, and it >> > > doesn't >> > > > > > seem >> > > > > > > to throw an >> > > > > > > > error, but it doesn't update /alias >> either. >> > > > > > > > Trying to access the server via the >> web page shows >> > > the >> > > > > old >> > > > > > > certificate >> > > > > > > > still in use. >> > > > > > > > I see the same
certificate
error >> with the replica >> > > > > server, >> > > > > > > which was freshly >> > > > > > > > rebuilt and added last
week.
>> > > > > > > > I've doubtless dug
further
into the >> hole trying to >> > > > > > > troubleshoot this, so I >> > > > > > > > probably need to start from the >> beginning again, >> > > and a >> > > > > > > pointer in the right >> > > > > > > > direction would be a
great
help! >> > > > > > > > >> > > > > > > > A getcert list shows all
the
>> certificates expiry >> > > dates >> > > > > well >> > > > > > > into the future. >> > > > > > > > >> > > > > > > > How can I get the certs back in >> sync? I've found a >> > > few >> > > > > > guides >> > > > > > > and most seem >> > > > > > > > to be for earlier versions, and I'm >> not sure if >> > > they're >> > > > > > still >> > > > > > > current. >> > > > > > > > >> > > > > > > > I can post whatever logs you think >> will help, I'm >> > > > > > afraid I'm >> > > > > > > not familiar >> > > > > > > > enough with them all to tell which >> are the most >> > > > > > relevant. Is >> > > > > > > there a guide >> > > > > > > > for the logs? >> > > > > > > > >> > > > > > > > Thanks for any help you can give, >> > > > > > > > >> > > > > > > > Thomas >> > > > > > > >> > > > > > > > >> _______________________________________________ >> > > > > > > > FreeIPA-users mailing
list --
>> > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > > > > > > > To unsubscribe send an email to >> > > > > > > >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> >> > > > > > > > Fedora Code of Conduct: >> > > > > > > https://getfedora.org/code-of-conduct.html >> > > > > > > > List Guidelines: >> > > > > > > >>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > > List Archives: >> > > > > > > >> > > > > > >> > > > > >> > >> >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > FreeIPA-users mailing list -- >> > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > To unsubscribe send an email to >> > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > >
I'm guessing I've hit the end of the line here, so I'll have to just reinstall the servers and start from scratch, there's very little config, so it shouldn't be to hard to rebuild.
For the client servers, can i just unjoin then join them to the new domain, or do I need to clear out stuff first? For a client machine that has FreeIPA users, will the home folders be picked up by the new user, or should I backup and restore them later?
Of course if anyone has a better idea I'm all ears!
Thomas
On Fri, Aug 3, 2018 at 5:45 PM Thomas Letherby xrs444@xrs444.net wrote:
I tried using the instructions here, given that the server certs are out of step with the CA cert:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
But when I go to submit the request using certutil as per here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
I get this error:
ipa: ERROR: cannot connect to 'any of the configured servers'
This is probably because Tomcat is failing to start. I've set HTTPD to ignore cert errors, and it's set to WARN in LDAP.
The Tomcat error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
Seem to be playing chase the error here, but if I can get Tomcat to start, I should be able to replace the certificates and be back up and running.
Any idea how to do that?
Thanks all!
Thomas
On Wed, Aug 1, 2018 at 8:35 PM Thomas Letherby xrs444@xrs444.net wrote:
I think I'm stuck in a bit of a catch 22 here, I can't update the cert because the cert it's replacing is bad. Is there a way to force it to ignore the existing cert when it goes to update?
Thomas
On Mon, Jul 23, 2018 at 8:59 PM Thomas Letherby xrs444@xrs444.net wrote:
Hello Brian,
No problem, I don't expect a SLA on a free mailing list! If it was mission critical I'd have thrown a wedge of cash at Red Hat a long time ago...
I do appreciate any help though, some of the documentation is a little sketchy in places, when my kids grow up a bit and I have time again perhaps I can help out there.
I ran the first command three times, then the second. The ipa-update threw the following error:
trying https://xipa1.i.domain.net/ipa/json [try 1]: Forwarding 'schema' to json server ' https://xipa1.i.domain.net/ipa/json' cannot connect to 'https://xipa1.i.domain.net/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) The ipa-certupdate command failed.
It now shows the following, with the O=Domain cert being in date: certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=DOMAIN,ST=Arizona,C=US CT,C,C
And the pki-tomcatd service fails to restart with the following error:
Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48).
Thanks again,
Thomas
On Mon, Jul 23, 2018 at 8:10 PM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it
should
have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
You almost NEVER want to run this command. This renews the CA certificate. Nothing else. There is really no point. It is good for another 20 years.
Is this correct? If I have to there's not many certificates issued,
and
replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy
to
try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's
not
going to be the end of the world.
I'm sorry. I've had your paste open for a week now and keep forgetting to respond :-(
So you somehow have a bogus CA entry, serial # 4097. I'm not sure where that came from, I assume some self-signed CA of yours. The issuer is O=DOMAIN,ST=Arizona,C=US. It needs to go.
Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You can never be too careful.
What I'd recommend is to delete all the CA certs using certutil -D -d /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three times.
Then run ipa-certupdate. This should refresh the list with the proper CAs. certutil -L to show them again. There should be only one. If Apache is working you can use that cert database, /etc/httpd/alias, for comparison purposes.
For extra points you can verify it without starting the service:
# certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f /etc/dirsrv/slapd-INSTANCE/pwdfile.txt
So you have an existing Server-Cert but I can't really be sure which CA signed it. The above will tell you if it is currently trusted. It is good for another 2 years.
rob
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Here's the full listing from slap-d and pki-tomcat: https://pastebin.com/vWf2WVkN Is there any other logs that could help right now? And it is very likely I ran that command,I think I've been through every guide and walk-through remotely related to this! Thomas On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <
rcritten@redhat.com
<mailto:rcritten@redhat.com>> wrote: Thomas Letherby wrote: > Well, after poking around with the dates and a few restarts
of
services, > IPA now starts seemingly cleanly at the current date,
although the
> clients still don't seem to want to trust the CA, and I'm still seeing > the old cert crop up. > > If I look at the cert that wasn't updating before, it now
seems to
> contain three certs, the expired one and two new with much longer expiry > dates. > > [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET>
IPA
CA" | grep Not > Not Before: Sun Jun 17 09:06:38 2018 > Not After : Thu Jun 17 09:06:38 2038 > Not Before: Sun Jun 17 07:24:26 2018 > Not After : Thu Jun 17 07:24:26 2038 > Not Before: Thu Jun 08 06:51:04 2017 > Not After : Mon Jun 18 06:51:04 2018 > > Is this correct, or has it not updated the certificate correctly, if so, > how do I clean it up? This is rather confusing output. I think we need to see the
full
certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point? rob > > Thanks, > > Thomas > > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS > <christophe.trefois@uni.lu <mailto:
christophe.trefois@uni.lu>
<mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>>> wrote: > > From that I know you could trigger a refresh by
restarting
certmonger. > >> On 9 Jul 2018, at 07:38, Thomas Letherby via
FreeIPA-users
>> <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> >> Hello Fraser, >> >> As I've been playing around with this before I dig in further I >> pulled the expiry for the certificates across all the places I >> know to look, if I have a cert listed, it's expired: >> >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> certutil -d /etc/httpd/alias -L >> Signing-Cert >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> getcert-list all up to date. >> >> ipa-getcert list all up to date >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> <http://i.domain.net/> IPA >> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" >> Expired >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate >> 1 - Expired >> 2 - Expired >> 3 - In date >> >> I've managed to narrow down the expiries to a crossover of one >> day, and setting the date to that day allows Tomcat-PKI to start, >> but the above results show that the certs haven't
updated
yet, but >> they may do in the next few hours? >> >> Thomas >> >> >> >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
>> >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: >> > Hello Fraser, >> > >> > The serial numbers appear to match, but if I run >> ipa-certupdate I get the >> > following: >> > >> > ipa-certupdate >> > trying https://server1.i.domain.net/ipa/json >> > Connection to https://server1.i.domain.net/ipa/json failed >> with [SSL: >> > CERTIFICATE_VERIFY_FAILED] certificate verify
failed
>> (_ssl.c:579) >> > >> > Tomcat is the only service that appears to be failing with >> the following >> > error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-8181) >> > Peer's Certificate has expired. (-1) >> > >> > But it should now be valid as I set the date
back.
If I set >> the date to >> > today I get this error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-12195) >> > Peer does not recognize and trust the CA that issued your >> certificate. (-1) >> > >> > Looks like it can't load because the certificate
it
uses >> isn't valid, if I >> > roll the clock back so the CA cert is, the
certificate
>> Tomcat is using >> > isn't valid and if I roll forward the CA cert
isn't.
>> > >> > How can I break this catch 22? >> > >> Which is the not-yet-valid certificate at the time
to
which you >> rolled back? The subsystemCert or the 389DS server certificate? >> >> In either case, you can look in the Dogtag certificate repository >> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the >> certificate that is valid at the relevant time.
Copy
the cert >> data >> (you can base64-decode the value to get the binary DER certificate >> data). Then you can delete the not-yet-valid-at-that-time >> certificate from the NSSDB and add the appropriate certificate >> using >> >> certutil -d <nssdb-path> -A -i <cert-path> >> >> If the certificate in question is the Dogtag subsystemCert, >> you will >> furthermore need to fix up the data in the uid=pkidbuser entry to >> match the "current" certificate. >> >> HTH, >> Fraser >> >> >> > Thanks, >> > >> > Thomas >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > wrote: >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700,
Thomas
Letherby >> wrote: >> > > > Hello all, >> > > > >> > > > Here's the info: >> > > > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L >> > > > >> > > > Certificate Nickname
>> Trust >> > > > Attributes >> > > > >> > > > SSL,S/MIME,JAR/XPI >> > > > >> > > > Server-Cert
>> u,u,u >> > > > O=domain,ST=Arizona,C=US
>> CT,C,C >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA >> CT,C,C >> > > > >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA is out of >> date for those. >> > > > >> > > Try running ipa-certupdate. It will update the IPA CA >> certificate >> > > in the various trust stores including the DS
NSSDB.
>> > > >> > > It reads the certificates from >> > > >> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > > >> > > so you should probably check that the
certificate
in that >> entry is >> > > up to date also. >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> > > -a >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > > > Matches >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > > > uid=pkidbuser,ou=people,o=ipaca
"(objectclass=*)"
>> usercertificate >> > > > >> > > > Thomas >> > > > >> > > > >> > > > >> > > > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob
Crittenden
>> <rcritten@redhat.com <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >> > > wrote: >> > > > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > > > > > Hello Florence, >> > > > > > >> > > > > > It was the Signing-Cert and the I.domain.NET <http://I.domain.NET> >> <http://i.domain.net/> <http://I.domain.NET >> <http://i.domain.net/>> >> > > IPA >> > > > > > CA cert. By setting the clock back I managed to get >> those to renew, >> > > now >> > > > > > it seems I just need to get tomcat-pki to start. >> > > > > > >> > > > > > The error is: >> > > > > > >> > > > > > Internal Database Error encountered:
Could not
>> connect to LDAP server >> > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> <http://xipa1.i.xrs444.net/> <
>> <http://xipa1.i.xrs444.net/>> port 636 Error >> > > > > > netscape.ldap.LDAPException: Unable to create socket: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> SSL_ForceHandshake failed: >> > > > > > (-12195) Peer does not recognize and
trust
the CA >> that issued your >> > > > > > certificate. (-1) >> > > > > > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > > > > > >> > > > > > Certificate Nickname
>> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Server-Cert cert-pki-ca
>> u,u,u >> > > > > > ocspSigningCert cert-pki-ca
>> u,u,u >> > > > > > O=domain,ST=Arizona,C=US
>> CT,C,C >> > > > > > auditSigningCert cert-pki-ca
>> u,u,Pu >> > > > > > subsystemCert cert-pki-ca
>> u,u,u >> > > > > > caSigningCert cert-pki-ca >> > > CTu,Cu,Cu >> > > > > > >> > > > > > These are all set to expire in 2020 or
beyond.
>> > > > > > >> > > > > > certutil -d /etc/httpd/alias -L
Server-Cert
>> > > > > > >> > > > > > Certificate Nickname
>> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Signing-Cert
>> u,u,u >> > > > > > O=xrs444,ST=Arizona,C=US
>> CT,C,C >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA >> > > > > > CT,C,C >> > > > > > Server-Cert
>> u,u,u >> > > > > > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA and Signing-Cert
are the
>> > > > > > expired certs here. >> > > > > >> > > > > Don't worry about Signing-Cert. It is the cert used to >> sign the jar >> > > file >> > > > > used to autoconfigure Firefox. You should never need >> to re-sign one >> > > > > again (and this method isn't allowed in modern Firefox >> anyway). >> > > > > >> > > > > rob >> > > > > >> > > > > > >> > > > > > Thomas >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud < >> > > flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>> >> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>>>> wrote: >> > > > > > >> > > > > > On 06/27/2018 07:02 AM, Thomas
Letherby via
>> FreeIPA-users wrote: >> > > > > > > After some fiddling with dates some more I >> seem to have the >> > > HTTPD >> > > > > > cert >> > > > > > > in sync, however it appears the
cert
signing >> cert is expired. >> > > > > > > >> > > > > > > named also says it's starting, but doesn't >> seem to want to >> > > respond. >> > > > > > > >> > > > > > > I don't have time to dig into it
more
tonight, >> but let me know >> > > what >> > > > > > > other information or tests I can
run
and I'll >> get them posted >> > > > > > tomorrow. >> > > > > > > >> > > > > > > Thanks all. >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < >> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> >> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:
xrs444@xrs444.net>>>
>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>>> wrote: >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > I think this is everything (domain name >> changed to protect >> > > the >> > > > > > > guilty!): >> > > > > > > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > > > > > > >> > > > > > Hi Thomas, >> > > > > > >> > > > > > in the provided pastebin, the error 'certutil: >> function failed: >> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key >> database is in an >> > > old, >> > > > > > unsupported format' can be easily explained: >> there is a typo in >> > > the >> > > > > > directory path. >> > > > > > You can try with certutil -d >> /etc/pki/pki-tomcat/alias -L -n >> > > > > <nickname> >> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). >> > > > > > >> > > > > > You mention that the cert signing
cert is
>> expired, can you >> > > clarify >> > > > > > which >> > > > > > certificate this is? Please provide
the
subject >> name, certificate >> > > > > > nickname and location. >> > > > > > >> > > > > > Flo >> > > > > > > I pulled the same on the
replica,
which >> appears to be >> > > playing >> > > > > > up too >> > > > > > > in a similar fashion. >> > > > > > > >> > > > > > > I did just notice the date on
the
replica >> is out, I never >> > > set >> > > > > it >> > > > > > > back when I was trying to get
the
cert to >> renew. >> > > > > > > >> > > > > > > Let me know if you need
anything
else. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser >> Tweedale >> > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>> >> > > > > wrote: >> > > > > > > >> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM >> -0700, Thomas >> > > Letherby >> > > > > via >> > > > > > > FreeIPA-users wrote: >> > > > > > > > Hello all, >> > > > > > > > I had an issue a short while ago >> with a replica >> > > which >> > > > > > turned >> > > > > > > out to be an >> > > > > > > > expired certificate
which
I renewed >> and all seemed >> > > good. >> > > > > > > > >> > > > > > > > Seemed... >> > > > > > > > >> > > > > > > > It now appears that although the >> certificate >> > > renewed as >> > > > > > seen >> > > > > > > by getcert >> > > > > > > > -list, it didn't update >> /etc/httpd/alias and so the >> > > > > > httpd and >> > > > > > > tomcat-pki >> > > > > > > > services won't start unless I set >> the date to >> > > before the >> > > > > > > certificate >> > > > > > > > expired, and even then sometimes >> the httpd error_log >> > > > > shows: >> > > > > > > > Unable to verify
certificate
>> 'Server-Cert'. Add >> > > > > > > "NSSEnforceValidCerts off" >> > > > > > > > to nss.conf so the
server
can start >> until the >> > > problem >> > > > > > can be >> > > > > > > resolved. >> > > > > > > > and the service fails to start. >> > > > > > > > >> > > > > > > Hi Thomas, >> > > > > > > >> > > > > > > Can you please show
`getcert
list` >> output on the >> > > server in >> > > > > > question, >> > > > > > > as well as the output of >> > > > > > > >> > > > > > > certutil -d /etc/httpd/alias -L >> Server-Cert >> > > > > > > >> > > > > > > and >> > > > > > > >> > > > > > > certutil -d >> /etc/pki/pki-tomcatd/alias -L >> > > <nickname> >> > > > > > > >> > > > > > > for each nickname in the >> /etc/pki/pki-tomcatd/alias >> > > NSSDB. >> > > > > > > >> > > > > > > And Certmonger journal output. And >> pki debug log >> > > > > > >
/var/log/pki/pki-tomcat/ca/debug.
>> > > > > > > >> > > > > > > It is strange that
`getcert list'
>> shows an up to date >> > > > > > certificate >> > > > > > > while the actual
certificate
that is >> being tracked is >> > > > > > expired... >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Fraser >> > > > > > > >> > > > > > > > I've tried resubmitting
the
>> certificate, and it >> > > doesn't >> > > > > > seem >> > > > > > > to throw an >> > > > > > > > error, but it doesn't update /alias >> either. >> > > > > > > > Trying to access the server via the >> web page shows >> > > the >> > > > > old >> > > > > > > certificate >> > > > > > > > still in use. >> > > > > > > > I see the same
certificate
error >> with the replica >> > > > > server, >> > > > > > > which was freshly >> > > > > > > > rebuilt and added last
week.
>> > > > > > > > I've doubtless dug
further
into the >> hole trying to >> > > > > > > troubleshoot this, so I >> > > > > > > > probably need to start from the >> beginning again, >> > > and a >> > > > > > > pointer in the right >> > > > > > > > direction would be a
great
help! >> > > > > > > > >> > > > > > > > A getcert list shows
all the
>> certificates expiry >> > > dates >> > > > > well >> > > > > > > into the future. >> > > > > > > > >> > > > > > > > How can I get the certs back in >> sync? I've found a >> > > few >> > > > > > guides >> > > > > > > and most seem >> > > > > > > > to be for earlier versions, and I'm >> not sure if >> > > they're >> > > > > > still >> > > > > > > current. >> > > > > > > > >> > > > > > > > I can post whatever logs you think >> will help, I'm >> > > > > > afraid I'm >> > > > > > > not familiar >> > > > > > > > enough with them all to tell which >> are the most >> > > > > > relevant. Is >> > > > > > > there a guide >> > > > > > > > for the logs? >> > > > > > > > >> > > > > > > > Thanks for any help you can give, >> > > > > > > > >> > > > > > > > Thomas >> > > > > > > >> > > > > > > > >> _______________________________________________ >> > > > > > > > FreeIPA-users mailing
list --
>> > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > > > > > > > To unsubscribe send an email to >> > > > > > > >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>>>> >> > > > > > > > Fedora Code of Conduct: >> > > > > > > https://getfedora.org/code-of-conduct.html >> > > > > > > > List Guidelines: >> > > > > > > >>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > > List Archives: >> > > > > > > >> > > > > > >> > > > > >> > >> >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > FreeIPA-users mailing list -- >> > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > To unsubscribe send an email to >> > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > >
Slightly different tack, following the guide here:
https://www.redhat.com/archives/freeipa-users/2017-January/msg00216.html
I got tomcat-pki to start, but ipa-certupdate gets the following error: CERTIFICATE_VERIFY_FAILED
Is there a way to get certupdate to ignore the cert? The cert is in date, but doesn't seem to be trusted I think?
Thomas
On Thu, Aug 9, 2018 at 10:04 PM Thomas Letherby xrs444@xrs444.net wrote:
I'm guessing I've hit the end of the line here, so I'll have to just reinstall the servers and start from scratch, there's very little config, so it shouldn't be to hard to rebuild.
For the client servers, can i just unjoin then join them to the new domain, or do I need to clear out stuff first? For a client machine that has FreeIPA users, will the home folders be picked up by the new user, or should I backup and restore them later?
Of course if anyone has a better idea I'm all ears!
Thomas
On Fri, Aug 3, 2018 at 5:45 PM Thomas Letherby xrs444@xrs444.net wrote:
I tried using the instructions here, given that the server certs are out of step with the CA cert:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
But when I go to submit the request using certutil as per here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
I get this error:
ipa: ERROR: cannot connect to 'any of the configured servers'
This is probably because Tomcat is failing to start. I've set HTTPD to ignore cert errors, and it's set to WARN in LDAP.
The Tomcat error is:
Internal Database Error encountered: Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
Seem to be playing chase the error here, but if I can get Tomcat to start, I should be able to replace the certificates and be back up and running.
Any idea how to do that?
Thanks all!
Thomas
On Wed, Aug 1, 2018 at 8:35 PM Thomas Letherby xrs444@xrs444.net wrote:
I think I'm stuck in a bit of a catch 22 here, I can't update the cert because the cert it's replacing is bad. Is there a way to force it to ignore the existing cert when it goes to update?
Thomas
On Mon, Jul 23, 2018 at 8:59 PM Thomas Letherby xrs444@xrs444.net wrote:
Hello Brian,
No problem, I don't expect a SLA on a free mailing list! If it was mission critical I'd have thrown a wedge of cash at Red Hat a long time ago...
I do appreciate any help though, some of the documentation is a little sketchy in places, when my kids grow up a bit and I have time again perhaps I can help out there.
I ran the first command three times, then the second. The ipa-update threw the following error:
trying https://xipa1.i.domain.net/ipa/json [try 1]: Forwarding 'schema' to json server ' https://xipa1.i.domain.net/ipa/json' cannot connect to 'https://xipa1.i.domain.net/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) The ipa-certupdate command failed.
It now shows the following, with the O=Domain cert being in date: certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u O=DOMAIN,ST=Arizona,C=US CT,C,C
And the pki-tomcatd service fails to restart with the following error:
Could not connect to LDAP server host xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException: Authentication failed (48).
Thanks again,
Thomas
On Mon, Jul 23, 2018 at 8:10 PM Rob Crittenden rcritten@redhat.com wrote:
Thomas Letherby wrote:
Reading up on the ipa-cacert-manage renew command, according to here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it
should
have created a new cert and superseded the old certificate, but in my case, perhaps because it has already expired it seems to be still relying on the old cert.
You almost NEVER want to run this command. This renews the CA certificate. Nothing else. There is really no point. It is good for another 20 years.
Is this correct? If I have to there's not many certificates issued,
and
replacing the CA cert on the clients isn't too hard I think so if there's a way of resetting the CA and re-issuing new certs I'm happy
to
try that, or just cut out the old cert and request new?
This isn't in production, so If I need to do something drastic it's
not
going to be the end of the world.
I'm sorry. I've had your paste open for a week now and keep forgetting to respond :-(
So you somehow have a bogus CA entry, serial # 4097. I'm not sure where that came from, I assume some self-signed CA of yours. The issuer is O=DOMAIN,ST=Arizona,C=US. It needs to go.
Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You can never be too careful.
What I'd recommend is to delete all the CA certs using certutil -D -d /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three times.
Then run ipa-certupdate. This should refresh the list with the proper CAs. certutil -L to show them again. There should be only one. If Apache is working you can use that cert database, /etc/httpd/alias, for comparison purposes.
For extra points you can verify it without starting the service:
# certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f /etc/dirsrv/slapd-INSTANCE/pwdfile.txt
So you have an existing Server-Cert but I can't really be sure which CA signed it. The above will tell you if it is currently trusted. It is good for another 2 years.
rob
Thanks,
Thomas
On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs444@xrs444.net mailto:xrs444@xrs444.net> wrote:
Here's the full listing from slap-d and pki-tomcat: https://pastebin.com/vWf2WVkN Is there any other logs that could help right now? And it is very likely I ran that command,I think I've been
through
every guide and walk-through remotely related to this! Thomas On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <
rcritten@redhat.com
<mailto:rcritten@redhat.com>> wrote: Thomas Letherby wrote: > Well, after poking around with the dates and a few
restarts of
services, > IPA now starts seemingly cleanly at the current date,
although the
> clients still don't seem to want to trust the CA, and I'm still seeing > the old cert crop up. > > If I look at the cert that wasn't updating before, it now
seems to
> contain three certs, the expired one and two new with much longer expiry > dates. > > [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET>
IPA
CA" | grep Not > Not Before: Sun Jun 17 09:06:38 2018 > Not After : Thu Jun 17 09:06:38 2038 > Not Before: Sun Jun 17 07:24:26 2018 > Not After : Thu Jun 17 07:24:26 2038 > Not Before: Thu Jun 08 06:51:04 2017 > Not After : Mon Jun 18 06:51:04 2018 > > Is this correct, or has it not updated the certificate correctly, if so, > how do I clean it up? This is rather confusing output. I think we need to see the
full
certutil -L -d output to know what is going on. Did you run ipa-cacert-manage renew at some point? rob > > Thanks, > > Thomas > > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS > <christophe.trefois@uni.lu <mailto:
christophe.trefois@uni.lu>
<mailto:christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>>> wrote: > > From that I know you could trigger a refresh by
restarting
certmonger. > >> On 9 Jul 2018, at 07:38, Thomas Letherby via
FreeIPA-users
>> <freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> >> Hello Fraser, >> >> As I've been playing around with this before I dig in further I >> pulled the expiry for the certificates across all the places I >> know to look, if I have a cert listed, it's expired: >> >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> certutil -d /etc/httpd/alias -L >> Signing-Cert >> I.DOMAIN.NET <http://I.DOMAIN.NET> <http://i.domain.net/> IPA CA >> >> getcert-list all up to date. >> >> ipa-getcert list all up to date >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> <http://i.domain.net/> IPA >>
CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net"
>> Expired >> >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate >> 1 - Expired >> 2 - Expired >> 3 - In date >> >> I've managed to narrow down the expiries to a
crossover
of one >> day, and setting the date to that day allows
Tomcat-PKI
to start, >> but the above results show that the certs haven't
updated
yet, but >> they may do in the next few hours? >> >> Thomas >> >> >> >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>
wrote:
>> >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote: >> > Hello Fraser, >> > >> > The serial numbers appear to match, but if I run >> ipa-certupdate I get the >> > following: >> > >> > ipa-certupdate >> > trying https://server1.i.domain.net/ipa/json >> > Connection to https://server1.i.domain.net/ipa/json failed >> with [SSL: >> > CERTIFICATE_VERIFY_FAILED] certificate verify
failed
>> (_ssl.c:579) >> > >> > Tomcat is the only service that appears to be failing with >> the following >> > error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-8181) >> > Peer's Certificate has expired. (-1) >> > >> > But it should now be valid as I set the date
back.
If I set >> the date to >> > today I get this error: >> > >> > Internal Database Error encountered: Could not connect to >> LDAP server host >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> <http://xipa1.i.xrs444.net/> port 636 >> Error netscape.ldap.LDAPException: Unable to >> > create socket:
org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake >> failed: (-12195) >> > Peer does not recognize and trust the CA that issued your >> certificate. (-1) >> > >> > Looks like it can't load because the
certificate it
uses >> isn't valid, if I >> > roll the clock back so the CA cert is, the
certificate
>> Tomcat is using >> > isn't valid and if I roll forward the CA cert
isn't.
>> > >> > How can I break this catch 22? >> > >> Which is the not-yet-valid certificate at the
time to
which you >> rolled back? The subsystemCert or the 389DS
server
certificate? >> >> In either case, you can look in the Dogtag certificate repository >> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the >> certificate that is valid at the relevant time.
Copy
the cert >> data >> (you can base64-decode the value to get the binary DER certificate >> data). Then you can delete the not-yet-valid-at-that-time >> certificate from the NSSDB and add the appropriate certificate >> using >> >> certutil -d <nssdb-path> -A -i <cert-path> >> >> If the certificate in question is the Dogtag subsystemCert, >> you will >> furthermore need to fix up the data in the uid=pkidbuser entry to >> match the "current" certificate. >> >> HTH, >> Fraser >> >> >> > Thanks, >> > >> > Thomas >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> <ftweedal@redhat.com <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > wrote: >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700,
Thomas
Letherby >> wrote: >> > > > Hello all, >> > > > >> > > > Here's the info: >> > > > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET
-L
>> > > > >> > > > Certificate Nickname
>> Trust >> > > > Attributes >> > > > >> > > > SSL,S/MIME,JAR/XPI >> > > > >> > > > Server-Cert
>> u,u,u >> > > > O=domain,ST=Arizona,C=US
>> CT,C,C >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA >> CT,C,C >> > > > >> > > > I.domain.NET <http://I.domain.NET> <http://i.domain.net/> IPA CA is out of >> date for those. >> > > > >> > > Try running ipa-certupdate. It will update
the
IPA CA >> certificate >> > > in the various trust stores including the DS
NSSDB.
>> > > >> > > It reads the certificates from >> > > >> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > > >> > > so you should probably check that the
certificate
in that >> entry is >> > > up to date also. >> > > >> > > Cheers, >> > > Fraser >> > > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert cert-pki-ca' >> > > -a >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > > > Matches >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > > > uid=pkidbuser,ou=people,o=ipaca
"(objectclass=*)"
>> usercertificate >> > > > >> > > > Thomas >> > > > >> > > > >> > > > >> > > > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob
Crittenden
>> <rcritten@redhat.com <mailto:rcritten@redhat.com> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >> > > wrote: >> > > > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > > > > > Hello Florence, >> > > > > > >> > > > > > It was the Signing-Cert and the I.domain.NET <http://I.domain.NET> >> <http://i.domain.net/> <http://I.domain.NET >> <http://i.domain.net/>> >> > > IPA >> > > > > > CA cert. By setting the clock back I managed to get >> those to renew, >> > > now >> > > > > > it seems I just need to get tomcat-pki
to
start. >> > > > > > >> > > > > > The error is: >> > > > > > >> > > > > > Internal Database Error encountered:
Could not
>> connect to LDAP server >> > > > > > host xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> <http://xipa1.i.xrs444.net/> <
>> <http://xipa1.i.xrs444.net/>> port 636 Error >> > > > > > netscape.ldap.LDAPException: Unable to create socket: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> SSL_ForceHandshake failed: >> > > > > > (-12195) Peer does not recognize and
trust
the CA >> that issued your >> > > > > > certificate. (-1) >> > > > > > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > > > > > >> > > > > > Certificate Nickname
>> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Server-Cert cert-pki-ca
>> u,u,u >> > > > > > ocspSigningCert cert-pki-ca
>> u,u,u >> > > > > > O=domain,ST=Arizona,C=US
>> CT,C,C >> > > > > > auditSigningCert cert-pki-ca
>> u,u,Pu >> > > > > > subsystemCert cert-pki-ca
>> u,u,u >> > > > > > caSigningCert cert-pki-ca >> > > CTu,Cu,Cu >> > > > > > >> > > > > > These are all set to expire in 2020 or
beyond.
>> > > > > > >> > > > > > certutil -d /etc/httpd/alias -L
Server-Cert
>> > > > > > >> > > > > > Certificate Nickname
>> Trust >> > > > > > Attributes >> > > > > > >> > > > > > SSL,S/MIME,JAR/XPI >> > > > > > >> > > > > > Signing-Cert
>> u,u,u >> > > > > > O=xrs444,ST=Arizona,C=US
>> CT,C,C >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA >> > > > > > CT,C,C >> > > > > > Server-Cert
>> u,u,u >> > > > > > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> <http://i.xrs444.net/> <http://I.XRS444.NET >> <http://i.xrs444.net/>> IPA CA and Signing-Cert
are the
>> > > > > > expired certs here. >> > > > > >> > > > > Don't worry about Signing-Cert. It is the cert used to >> sign the jar >> > > file >> > > > > used to autoconfigure Firefox. You should never need >> to re-sign one >> > > > > again (and this method isn't allowed in modern Firefox >> anyway). >> > > > > >> > > > > rob >> > > > > >> > > > > > >> > > > > > Thomas >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM
Florence
Blanc-Renaud < >> > > flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>> >> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com> <mailto:flo@redhat.com <mailto:flo@redhat.com>>>> wrote: >> > > > > > >> > > > > > On 06/27/2018 07:02 AM, Thomas
Letherby via
>> FreeIPA-users wrote: >> > > > > > > After some fiddling with dates
some
more I >> seem to have the >> > > HTTPD >> > > > > > cert >> > > > > > > in sync, however it appears the
cert
signing >> cert is expired. >> > > > > > > >> > > > > > > named also says it's starting, but doesn't >> seem to want to >> > > respond. >> > > > > > > >> > > > > > > I don't have time to dig into it
more
tonight, >> but let me know >> > > what >> > > > > > > other information or tests I can
run
and I'll >> get them posted >> > > > > > tomorrow. >> > > > > > > >> > > > > > > Thanks all. >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby < >> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> >> > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:
xrs444@xrs444.net>>>
>> > > > > > > <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net> >> <mailto:xrs444@xrs444.net <mailto:xrs444@xrs444.net>>>>> wrote: >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > I think this is everything (domain name >> changed to protect >> > > the >> > > > > > > guilty!): >> > > > > > > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > > > > > > >> > > > > > Hi Thomas, >> > > > > > >> > > > > > in the provided pastebin, the error 'certutil: >> function failed: >> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key >> database is in an >> > > old, >> > > > > > unsupported format' can be easily explained: >> there is a typo in >> > > the >> > > > > > directory path. >> > > > > > You can try with certutil -d >> /etc/pki/pki-tomcat/alias -L -n >> > > > > <nickname> >> > > > > > (note the pki-tomcat instead of pki-tomcat*d*). >> > > > > > >> > > > > > You mention that the cert signing
cert is
>> expired, can you >> > > clarify >> > > > > > which >> > > > > > certificate this is? Please provide
the
subject >> name, certificate >> > > > > > nickname and location. >> > > > > > >> > > > > > Flo >> > > > > > > I pulled the same on the
replica,
which >> appears to be >> > > playing >> > > > > > up too >> > > > > > > in a similar fashion. >> > > > > > > >> > > > > > > I did just notice the date on
the
replica >> is out, I never >> > > set >> > > > > it >> > > > > > > back when I was trying to get
the
cert to >> renew. >> > > > > > > >> > > > > > > Let me know if you need
anything
else. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Thomas >> > > > > > > >> > > > > > > On Sun, Jun 24, 2018 at 8:43
PM
Fraser >> Tweedale >> > > > > > <ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>> >> > > > > > > <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com> >> <mailto:ftweedal@redhat.com <mailto:ftweedal@redhat.com>>>>> >> > > > > wrote: >> > > > > > > >> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM >> -0700, Thomas >> > > Letherby >> > > > > via >> > > > > > > FreeIPA-users wrote: >> > > > > > > > Hello all, >> > > > > > > > I had an issue a short while ago >> with a replica >> > > which >> > > > > > turned >> > > > > > > out to be an >> > > > > > > > expired certificate
which
I renewed >> and all seemed >> > > good. >> > > > > > > > >> > > > > > > > Seemed... >> > > > > > > > >> > > > > > > > It now appears that although the >> certificate >> > > renewed as >> > > > > > seen >> > > > > > > by getcert >> > > > > > > > -list, it didn't update >> /etc/httpd/alias and so the >> > > > > > httpd and >> > > > > > > tomcat-pki >> > > > > > > > services won't start unless I set >> the date to >> > > before the >> > > > > > > certificate >> > > > > > > > expired, and even then sometimes >> the httpd error_log >> > > > > shows: >> > > > > > > > Unable to verify
certificate
>> 'Server-Cert'. Add >> > > > > > > "NSSEnforceValidCerts off" >> > > > > > > > to nss.conf so the
server
can start >> until the >> > > problem >> > > > > > can be >> > > > > > > resolved. >> > > > > > > > and the service fails
to
start. >> > > > > > > > >> > > > > > > Hi Thomas, >> > > > > > > >> > > > > > > Can you please show
`getcert
list` >> output on the >> > > server in >> > > > > > question, >> > > > > > > as well as the output of >> > > > > > > >> > > > > > > certutil -d /etc/httpd/alias -L >> Server-Cert >> > > > > > > >> > > > > > > and >> > > > > > > >> > > > > > > certutil -d >> /etc/pki/pki-tomcatd/alias -L >> > > <nickname> >> > > > > > > >> > > > > > > for each nickname in the >> /etc/pki/pki-tomcatd/alias >> > > NSSDB. >> > > > > > > >> > > > > > > And Certmonger journal output. And >> pki debug log >> > > > > > >
/var/log/pki/pki-tomcat/ca/debug.
>> > > > > > > >> > > > > > > It is strange that
`getcert list'
>> shows an up to date >> > > > > > certificate >> > > > > > > while the actual
certificate
that is >> being tracked is >> > > > > > expired... >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Fraser >> > > > > > > >> > > > > > > > I've tried
resubmitting the
>> certificate, and it >> > > doesn't >> > > > > > seem >> > > > > > > to throw an >> > > > > > > > error, but it doesn't update /alias >> either. >> > > > > > > > Trying to access the server via the >> web page shows >> > > the >> > > > > old >> > > > > > > certificate >> > > > > > > > still in use. >> > > > > > > > I see the same
certificate
error >> with the replica >> > > > > server, >> > > > > > > which was freshly >> > > > > > > > rebuilt and added last
week.
>> > > > > > > > I've doubtless dug
further
into the >> hole trying to >> > > > > > > troubleshoot this, so I >> > > > > > > > probably need to start from the >> beginning again, >> > > and a >> > > > > > > pointer in the right >> > > > > > > > direction would be a
great
help! >> > > > > > > > >> > > > > > > > A getcert list shows
all the
>> certificates expiry >> > > dates >> > > > > well >> > > > > > > into the future. >> > > > > > > > >> > > > > > > > How can I get the certs back in >> sync? I've found a >> > > few >> > > > > > guides >> > > > > > > and most seem >> > > > > > > > to be for earlier versions, and I'm >> not sure if >> > > they're >> > > > > > still >> > > > > > > current. >> > > > > > > > >> > > > > > > > I can post whatever
logs
you think >> will help, I'm >> > > > > > afraid I'm >> > > > > > > not familiar >> > > > > > > > enough with them all to tell which >> are the most >> > > > > > relevant. Is >> > > > > > > there a guide >> > > > > > > > for the logs? >> > > > > > > > >> > > > > > > > Thanks for any help you can give, >> > > > > > > > >> > > > > > > > Thomas >> > > > > > > >> > > > > > > > >> _______________________________________________ >> > > > > > > > FreeIPA-users mailing
list --
>> > > > > > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > > > > > > > To unsubscribe send an email to >> > > > > > > >> freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>>> >> > > > > > > >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > > >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>>>> >> > > > > > > > Fedora Code of Conduct: >> > > > > > > https://getfedora.org/code-of-conduct.html >> > > > > > > > List Guidelines: >> > > > > > > >>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > > List Archives: >> > > > > > > >> > > > > > >> > > > > >> > >> >
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > FreeIPA-users mailing list -- >> > > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> >> > > > > > <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> <mailto:freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>>> >> > > > > > > To unsubscribe send an email to >> > > > > > freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> >> <mailto:
freeipa-users-leave@lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>> >> > > > > >
freeipa-users@lists.fedorahosted.org