I have a weird issue where I have my RHV (RedHat Virtualization) environment system that has an IPA-issued certificate in place. This has been working very well for some time.
In any case, I'm suddenly finding that browsers are telling me the certificate is invalid, yet when I check things (I issue certs with properly SANs just to clarify that point), everything seems to be ok and in place.
I tried stop-tracking and reissuing a new cert thinking that something was wrong as I had recently removed/rebuilt my secondary IPA server due to what I believed were replication issues. This has looked very good since then (at least a month).
When I try and go to the URL in Chrome, I'm getting: NET::ERR_CERT_REVOKED
Safari (as a test) denies the cert as well.
When I look at things on the system via ipa-getcert: ----- [root@orldc-prod-vengine ~]# ipa-getcert list Number of certificates and requests being tracked: 1. Request ID '20200211221958': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/ovirt-engine/keys/apache.key.nopass' certificate: type=FILE,location='/etc/pki/ovirt-engine/certs/apache.cer' CA: IPA issuer: CN=Certificate Authority,O=PASSUR.LOCAL subject: CN=orldc-prod-vengine.passur.local,O=PASSUR.LOCAL expires: 2024-02-11 22:20:00 UTC dns: orldc-prod-vengine.passur.local principal name: HTTP/orldc-prod-vengine.passur.local@PASSUR.LOCAL key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes -----
If I search for the cert via the IPA webUI, I see the certificate there and it shows as valid (with the correct Serial number).
I've also at least verified that OCSP and CRL URLs at least function (I get a response and I download a CRL). I'm just not sure how to parse things and verify.
I'm trying to get steps on how best to troubleshoot this as this is currently preventing me from managing my RHV environment (which is a serious problem). Please let me know if you have any guidance. I need some help!
-- Chris
On Tue, Feb 11, 2020 at 05:40:14PM -0500, Christopher Young via FreeIPA-users wrote:
I have a weird issue where I have my RHV (RedHat Virtualization) environment system that has an IPA-issued certificate in place. This has been working very well for some time.
In any case, I'm suddenly finding that browsers are telling me the certificate is invalid, yet when I check things (I issue certs with properly SANs just to clarify that point), everything seems to be ok and in place.
I tried stop-tracking and reissuing a new cert thinking that something was wrong as I had recently removed/rebuilt my secondary IPA server due to what I believed were replication issues. This has looked very good since then (at least a month).
When I try and go to the URL in Chrome, I'm getting: NET::ERR_CERT_REVOKED
Safari (as a test) denies the cert as well.
When I look at things on the system via ipa-getcert:
[root@orldc-prod-vengine ~]# ipa-getcert list Number of certificates and requests being tracked: 1. Request ID '20200211221958': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/ovirt-engine/keys/apache.key.nopass' certificate: type=FILE,location='/etc/pki/ovirt-engine/certs/apache.cer' CA: IPA issuer: CN=Certificate Authority,O=PASSUR.LOCAL subject: CN=orldc-prod-vengine.passur.local,O=PASSUR.LOCAL expires: 2024-02-11 22:20:00 UTC dns: orldc-prod-vengine.passur.local principal name: HTTP/orldc-prod-vengine.passur.local@PASSUR.LOCAL key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes
If I search for the cert via the IPA webUI, I see the certificate there and it shows as valid (with the correct Serial number).
I've also at least verified that OCSP and CRL URLs at least function (I get a response and I download a CRL). I'm just not sure how to parse things and verify.
Use `openssl crl -text < FILE` to pretty-print a CRL.
Use `openssl ocsp` to perform an OCSP request:
openssl ocsp -resp_text \ -CAfile /etc/ipa/ca.crt \ -url http://$HOST:8080/ca/ocsp \ -issuer /etc/ipa/ca.crt -serial $SERIAL_IN_DECIMAL
I'm trying to get steps on how best to troubleshoot this as this is currently preventing me from managing my RHV environment (which is a serious problem). Please let me know if you have any guidance. I need some help!
To be sure, also check that the issuer certificate and any other certificates in the chain have not been revoked.
Let us know how you go.
Cheers, Fraser
Interesting enough, I don't get this problem on my Fedora workstation or a co-worker on a Windows-based system, so I'm currently troubleshooting it as an issue on the Mac (which has Symantec Endpoint Protection on it that I _wonder_ might be doing something here) until I prove otherwise. I would like to be able to validate everything as much as possible to eliminate the FreeIPA environment.
I did use the command just to check and got good responses (Once I got the URLs correct): ----- Response verify OK 805240912: good This Update: Feb 12 22:52:44 2020 GMT -----
On Tue, Feb 11, 2020 at 11:02 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Tue, Feb 11, 2020 at 05:40:14PM -0500, Christopher Young via FreeIPA-users wrote:
I have a weird issue where I have my RHV (RedHat Virtualization) environment system that has an IPA-issued certificate in place. This has been working very well for some time.
In any case, I'm suddenly finding that browsers are telling me the certificate is invalid, yet when I check things (I issue certs with properly SANs just to clarify that point), everything seems to be ok and in place.
I tried stop-tracking and reissuing a new cert thinking that something was wrong as I had recently removed/rebuilt my secondary IPA server due to what I believed were replication issues. This has looked very good since then (at least a month).
When I try and go to the URL in Chrome, I'm getting: NET::ERR_CERT_REVOKED
Safari (as a test) denies the cert as well.
When I look at things on the system via ipa-getcert:
[root@orldc-prod-vengine ~]# ipa-getcert list Number of certificates and requests being tracked: 1. Request ID '20200211221958': status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/pki/ovirt-engine/keys/apache.key.nopass' certificate: type=FILE,location='/etc/pki/ovirt-engine/certs/apache.cer' CA: IPA issuer: CN=Certificate Authority,O=PASSUR.LOCAL subject: CN=orldc-prod-vengine.passur.local,O=PASSUR.LOCAL expires: 2024-02-11 22:20:00 UTC dns: orldc-prod-vengine.passur.local principal name: HTTP/orldc-prod-vengine.passur.local@PASSUR.LOCAL key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes
If I search for the cert via the IPA webUI, I see the certificate there and it shows as valid (with the correct Serial number).
I've also at least verified that OCSP and CRL URLs at least function (I get a response and I download a CRL). I'm just not sure how to parse things and verify.
Use `openssl crl -text < FILE` to pretty-print a CRL.
Use `openssl ocsp` to perform an OCSP request:
openssl ocsp -resp_text \ -CAfile /etc/ipa/ca.crt \ -url http://$HOST:8080/ca/ocsp \ -issuer /etc/ipa/ca.crt -serial $SERIAL_IN_DECIMAL
I'm trying to get steps on how best to troubleshoot this as this is currently preventing me from managing my RHV environment (which is a serious problem). Please let me know if you have any guidance. I need some help!
To be sure, also check that the issuer certificate and any other certificates in the chain have not been revoked.
Let us know how you go.
Cheers, Fraser
On Wed, Feb 12, 2020 at 05:54:34PM -0500, Christopher Young wrote:
Interesting enough, I don't get this problem on my Fedora workstation or a co-worker on a Windows-based system, so I'm currently troubleshooting it as an issue on the Mac (which has Symantec Endpoint Protection on it that I _wonder_ might be doing something here) until I prove otherwise. I would like to be able to validate everything as much as possible to eliminate the FreeIPA environment.
Is it possible to disable the Symantic Endpoint Protection and see if the problem goes away? Or to somehow trace the program to to obtain evidence for or against the hypothesis?
Cheers, Fraser
I think I found the issue (posting here in case someone else runs into something similar). It's Apple's doing. https://podtech.io/os/mac-osx/chrome-catalina-certificate-issue/
Basically, I have my default certificate date length to 4 years (since our environment is small and these rarely ever change). In any case, this is no-good with Apple starting with Catalina.
------ (from the link) ----- For certificates issued after 2019-07-01:
The ExtendedKeyUsage extension must be present, with the id-kp-ServerAuth OID. The validity period may not be longer than 825 days. ----- -----
So, I guess I'm going to have to _actually_ revoke a bunch of certs and re-issue them as 2 year certs instead in order to satisfy my MacOS users (which is quite a few). This is a serious pain, but I thought I would post here just in case anyone else with an internal CA (and using longer cert expiration lengths) isn't aware.
Thanks for helping me troubleshoot and verify the IPA side of things!
-- Chris
On Wed, Feb 12, 2020 at 6:39 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Feb 12, 2020 at 05:54:34PM -0500, Christopher Young wrote:
Interesting enough, I don't get this problem on my Fedora workstation or a co-worker on a Windows-based system, so I'm currently troubleshooting it as an issue on the Mac (which has Symantec Endpoint Protection on it that I _wonder_ might be doing something here) until I prove otherwise. I would like to be able to validate everything as much as possible to eliminate the FreeIPA environment.
Is it possible to disable the Symantic Endpoint Protection and see if the problem goes away? Or to somehow trace the program to to obtain evidence for or against the hypothesis?
Cheers, Fraser
On Wed, Feb 12, 2020 at 07:41:00PM -0500, Christopher Young wrote:
I think I found the issue (posting here in case someone else runs into something similar). It's Apple's doing. https://podtech.io/os/mac-osx/chrome-catalina-certificate-issue/
Basically, I have my default certificate date length to 4 years (since our environment is small and these rarely ever change). In any case, this is no-good with Apple starting with Catalina.
------ (from the link) ----- For certificates issued after 2019-07-01:
The ExtendedKeyUsage extension must be present, with the id-kp-ServerAuth OID. The validity period may not be longer than 825 days.
So, I guess I'm going to have to _actually_ revoke a bunch of certs and re-issue them as 2 year certs instead in order to satisfy my MacOS users (which is quite a few). This is a serious pain, but I thought I would post here just in case anyone else with an internal CA (and using longer cert expiration lengths) isn't aware.
Thanks for helping me troubleshoot and verify the IPA side of things!
-- Chris
Thanks Chris, this is good to know.
You will have to change the profile and issue new certs. You don't have to revoke the old certs, but it won't hurt.
Cheers, Fraser
On Wed, Feb 12, 2020 at 6:39 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Feb 12, 2020 at 05:54:34PM -0500, Christopher Young wrote:
Interesting enough, I don't get this problem on my Fedora workstation or a co-worker on a Windows-based system, so I'm currently troubleshooting it as an issue on the Mac (which has Symantec Endpoint Protection on it that I _wonder_ might be doing something here) until I prove otherwise. I would like to be able to validate everything as much as possible to eliminate the FreeIPA environment.
Is it possible to disable the Symantic Endpoint Protection and see if the problem goes away? Or to somehow trace the program to to obtain evidence for or against the hypothesis?
Cheers, Fraser
freeipa-users@lists.fedorahosted.org
-
Christopher Young -
Fraser Tweedale