Hello,
I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4
Today the certificate of my IMAP server (running on Debian Buster) was automatically refreshed:
,---- | Request ID '20181003215953': | status: MONITORING | stuck: no | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' | CA: IPA | issuer: CN=Certificate Authority,O=JOCHEN.ORG | subject: CN=imap.jochen.org,O=JOCHEN.ORG | expires: 2022-09-07 09:30:16 CEST | dns: imap.jochen.org | principal name: imap/jupiter.jochen.org@JOCHEN.ORG | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment | eku: id-kp-serverAuth,id-kp-clientAuth | pre-save command: | post-save command: /root/refresh_cyrus_certificate.sh | track: yes | auto-renew: yes `----
On an iPhone one of my users gets a message that the certificate is not valid. Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
When I look at the certificate with openssl I see:
,---- | X509v3 extensions: | X509v3 Authority Key Identifier: | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 | | Authority Information Access: | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp | | X509v3 Key Usage: critical | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment | X509v3 Extended Key Usage: | TLS Web Server Authentication, TLS Web Client Authentication `----
My current guess is that the "Key Usage: critical" is the reason for the iOS error.
I've looked for the certprofiles and found these files:
,---- | [root@freeipa3 /]# find . -name *caIPAserviceCert* -ls | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg `----
These files contain:
,---- | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false `----
So I think this is where the critical comes from and the keyUsage defaults come from.
What I could use help with is the following:
1. I didn't find reports about the problem in pagure or the mailing list. Am I really alone with this?
2. My FreeIPA has been installed years ago on Fedora, moved to CentOS and this year back to Fedora by creating replicas. Has there been a problem with upgrading the certprofiles?
3. How can I remove the options from the certificate request so that certmonger gets a valid certificate?
Do I miss something else?
Hello,
First of all: is the IPA CA certificate (or if it is externally signed, one of the superior certificates) in the trust store on the user's iPhone?
Other comments inline.
On Sun, Sep 06, 2020 at 11:24:22AM +0200, Jochen Kellner via FreeIPA-users wrote:
Hello,
I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4
Today the certificate of my IMAP server (running on Debian Buster) was automatically refreshed:
,---- | Request ID '20181003215953': | status: MONITORING | stuck: no | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' | CA: IPA | issuer: CN=Certificate Authority,O=JOCHEN.ORG | subject: CN=imap.jochen.org,O=JOCHEN.ORG | expires: 2022-09-07 09:30:16 CEST | dns: imap.jochen.org | principal name: imap/jupiter.jochen.org@JOCHEN.ORG | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment | eku: id-kp-serverAuth,id-kp-clientAuth | pre-save command: | post-save command: /root/refresh_cyrus_certificate.sh | track: yes | auto-renew: yes `----
On an iPhone one of my users gets a message that the certificate is not valid.
Was the previous certificate accepted, and the problem only occurs with the new certificate. You did mention the recent renewal, but you please clarify on this point?
Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
This article does not suggest any reason why iOS would consider the certificate invalid. If I missed something, please elaborate.
When I look at the certificate with openssl I see:
,---- | X509v3 extensions: | X509v3 Authority Key Identifier: | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 | | Authority Information Access: | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp | | X509v3 Key Usage: critical | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment | X509v3 Extended Key Usage: | TLS Web Server Authentication, TLS Web Client Authentication `----
My current guess is that the "Key Usage: critical" is the reason for the iOS error.
This is almost certainly not the issue. "Critical" just means that a verifier must understand and process the extension, or else fail. Per RFC 5280 the Key Usage extension SHOULD be marked critical. The asserted values are appropriate for a TLS server.
I've looked for the certprofiles and found these files:
,---- | [root@freeipa3 /]# find . -name *caIPAserviceCert* -ls | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg `----
These files contain:
,---- | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false `----
So I think this is where the critical comes from and the keyUsage defaults come from.
What I could use help with is the following:
- I didn't find reports about the problem in pagure or the mailing
list. Am I really alone with this?
Possibly, or you could be the canary in the coal mine :) You should first confirm that the affect iOS system actually trusts the CA certificate before pursuing other lines of investigation.
- My FreeIPA has been installed years ago on Fedora, moved to CentOS
and this year back to Fedora by creating replicas. Has there been a problem with upgrading the certprofiles?
I think the profile configuration is fine.
- How can I remove the options from the certificate request so that
certmonger gets a valid certificate?
Not relevant.
Do I miss something else?
If it is not a CA trust issue, the next thing I would suggest to try is to modify the caIPAserviceCert profile to issue a certificate with a validity period of <398 days. Browsers recently implemented a change that certificates issued from September 2020 must have a maximum validity period of 398 days. This change SHOULD only apply for certification paths ending at publicly trusted CAs. But maybe Apple pushed an update that applies it across the board.
To modify the profile:
1. export the configuration: `ipa certprofile-show --out profile.cfg caIPAserviceCert`
2. edit the validity period in the profile configuration: policyset.serverCertSet.2.constraint.params.range=380
3. modify the profile `ipa certprofile-mod --file profile.cfg caIPAserviceCert`
4. On the IMAP server host use certmonger to reissue the IMAP certificate: `getcert resubmit -i 20181003215953`
Cheers, Fraser
Hello,
thanks for your suggestions, I'll answer below. TL;DR: seems to work now.
Fraser Tweedale via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
First of all: is the IPA CA certificate (or if it is externally signed, one of the superior certificates) in the trust store on the user's iPhone?
I use the CA from FreeIPA and the CA certificate has been imported in the trust store. Using a web browser to access an internal website with an (older) IPA issued certificate works/validates fine.
On Sun, Sep 06, 2020 at 11:24:22AM +0200, Jochen Kellner via FreeIPA-users wrote:
Hello,
I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4
Today the certificate of my IMAP server (running on Debian Buster) was automatically refreshed:
,---- | Request ID '20181003215953': | status: MONITORING | stuck: no | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' | CA: IPA | issuer: CN=Certificate Authority,O=JOCHEN.ORG | subject: CN=imap.jochen.org,O=JOCHEN.ORG | expires: 2022-09-07 09:30:16 CEST | dns: imap.jochen.org | principal name: imap/jupiter.jochen.org@JOCHEN.ORG | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment | eku: id-kp-serverAuth,id-kp-clientAuth | pre-save command: | post-save command: /root/refresh_cyrus_certificate.sh | track: yes | auto-renew: yes `----
On an iPhone one of my users gets a message that the certificate is not valid.
Was the previous certificate accepted, and the problem only occurs with the new certificate. You did mention the recent renewal, but you please clarify on this point?
Yes, the old certificate was accepted without problems. Only after the renewal the user got these messages.
Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
This article does not suggest any reason why iOS would consider the certificate invalid. If I missed something, please elaborate.
This is the part:
The new requirements for an SSL certificate to be accepted by iOS 13 and macOS 10.15 are given in https://support.apple.com/en-us/HT210176. The key points are:
Key size must be greater than or equal to 2048 bits. Certificate must have a validity period of 825 days or fewer. Don't sign the certificate with SHA-1. DNS name must be in the Subject Alternative Name extension of the certificate. Certificate must have an ExtendedKeyUsage containing serverAuth.
When I look at the certificate with openssl I see:
,---- | X509v3 extensions: | X509v3 Authority Key Identifier: | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 | | Authority Information Access: | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp | | X509v3 Key Usage: critical | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment | X509v3 Extended Key Usage: | TLS Web Server Authentication, TLS Web Client Authentication `----
My current guess is that the "Key Usage: critical" is the reason for the iOS error.
This is almost certainly not the issue. "Critical" just means that a verifier must understand and process the extension, or else fail. Per RFC 5280 the Key Usage extension SHOULD be marked critical. The asserted values are appropriate for a TLS server.
Ok.
I've looked for the certprofiles and found these files:
,---- | [root@freeipa3 /]# find . -name *caIPAserviceCert* -ls | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg `----
These files contain:
,---- | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false `----
So I think this is where the critical comes from and the keyUsage defaults come from.
What I could use help with is the following:
- I didn't find reports about the problem in pagure or the mailing
list. Am I really alone with this?
Possibly, or you could be the canary in the coal mine :) You should first confirm that the affect iOS system actually trusts the CA certificate before pursuing other lines of investigation.
Ok, I'll recheck. And that really was an issue: The CA certificate had been imported into the trust store. In another settings menue (german iOS: Info -> Zertifikatsvertrauensstellung) the CA was not marked as trusted. We've enabled that and right now didn't get the error messages while getting new mail.
I'll have the user monitor and confirm, but hopefully we can close this case.
- My FreeIPA has been installed years ago on Fedora, moved to CentOS
and this year back to Fedora by creating replicas. Has there been a problem with upgrading the certprofiles?
I think the profile configuration is fine.
Thanks for the confirmation.
- How can I remove the options from the certificate request so that
certmonger gets a valid certificate?
Not relevant.
Do I miss something else?
If it is not a CA trust issue, the next thing I would suggest to try is to modify the caIPAserviceCert profile to issue a certificate with a validity period of <398 days. Browsers recently implemented a change that certificates issued from September 2020 must have a maximum validity period of 398 days. This change SHOULD only apply for certification paths ending at publicly trusted CAs. But maybe Apple pushed an update that applies it across the board.
To modify the profile:
export the configuration: `ipa certprofile-show --out profile.cfg caIPAserviceCert`
edit the validity period in the profile configuration: policyset.serverCertSet.2.constraint.params.range=380
modify the profile `ipa certprofile-mod --file profile.cfg caIPAserviceCert`
On the IMAP server host use certmonger to reissue the IMAP certificate: `getcert resubmit -i 20181003215953`
Maybe that's a good idea anyway - when certificates get renewed every couple of month like letsencrypt I'll find errors in the renewal much earlier. If the renewal is manual a long validity period is useful, but when everything is automatically a short validity period is no hassle and indeed useful to catch errors early.
Jochen
On Mon, Sep 07, 2020 at 05:52:12PM +0200, Jochen Kellner wrote:
Hello,
thanks for your suggestions, I'll answer below. TL;DR: seems to work now.
Fraser Tweedale via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
First of all: is the IPA CA certificate (or if it is externally signed, one of the superior certificates) in the trust store on the user's iPhone?
I use the CA from FreeIPA and the CA certificate has been imported in the trust store. Using a web browser to access an internal website with an (older) IPA issued certificate works/validates fine.
On Sun, Sep 06, 2020 at 11:24:22AM +0200, Jochen Kellner via FreeIPA-users wrote:
Hello,
I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4
Today the certificate of my IMAP server (running on Debian Buster) was automatically refreshed:
,---- | Request ID '20181003215953': | status: MONITORING | stuck: no | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' | CA: IPA | issuer: CN=Certificate Authority,O=JOCHEN.ORG | subject: CN=imap.jochen.org,O=JOCHEN.ORG | expires: 2022-09-07 09:30:16 CEST | dns: imap.jochen.org | principal name: imap/jupiter.jochen.org@JOCHEN.ORG | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment | eku: id-kp-serverAuth,id-kp-clientAuth | pre-save command: | post-save command: /root/refresh_cyrus_certificate.sh | track: yes | auto-renew: yes `----
On an iPhone one of my users gets a message that the certificate is not valid.
Was the previous certificate accepted, and the problem only occurs with the new certificate. You did mention the recent renewal, but you please clarify on this point?
Yes, the old certificate was accepted without problems. Only after the renewal the user got these messages.
Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
This article does not suggest any reason why iOS would consider the certificate invalid. If I missed something, please elaborate.
This is the part:
The new requirements for an SSL certificate to be accepted by iOS 13 and macOS 10.15 are given in https://support.apple.com/en-us/HT210176. The key points are:
Key size must be greater than or equal to 2048 bits. Certificate must have a validity period of 825 days or fewer. Don't sign the certificate with SHA-1. DNS name must be in the Subject Alternative Name extension of the certificate. Certificate must have an ExtendedKeyUsage containing serverAuth.When I look at the certificate with openssl I see:
,---- | X509v3 extensions: | X509v3 Authority Key Identifier: | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 | | Authority Information Access: | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp | | X509v3 Key Usage: critical | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment | X509v3 Extended Key Usage: | TLS Web Server Authentication, TLS Web Client Authentication `----
My current guess is that the "Key Usage: critical" is the reason for the iOS error.
This is almost certainly not the issue. "Critical" just means that a verifier must understand and process the extension, or else fail. Per RFC 5280 the Key Usage extension SHOULD be marked critical. The asserted values are appropriate for a TLS server.
Ok.
I've looked for the certprofiles and found these files:
,---- | [root@freeipa3 /]# find . -name *caIPAserviceCert* -ls | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg `----
These files contain:
,---- | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false `----
So I think this is where the critical comes from and the keyUsage defaults come from.
What I could use help with is the following:
- I didn't find reports about the problem in pagure or the mailing
list. Am I really alone with this?
Possibly, or you could be the canary in the coal mine :) You should first confirm that the affect iOS system actually trusts the CA certificate before pursuing other lines of investigation.
Ok, I'll recheck. And that really was an issue: The CA certificate had been imported into the trust store. In another settings menue (german iOS: Info -> Zertifikatsvertrauensstellung) the CA was not marked as trusted. We've enabled that and right now didn't get the error messages while getting new mail.
I'll have the user monitor and confirm, but hopefully we can close this case.
- My FreeIPA has been installed years ago on Fedora, moved to CentOS
and this year back to Fedora by creating replicas. Has there been a problem with upgrading the certprofiles?
I think the profile configuration is fine.
Thanks for the confirmation.
- How can I remove the options from the certificate request so that
certmonger gets a valid certificate?
Not relevant.
Do I miss something else?
If it is not a CA trust issue, the next thing I would suggest to try is to modify the caIPAserviceCert profile to issue a certificate with a validity period of <398 days. Browsers recently implemented a change that certificates issued from September 2020 must have a maximum validity period of 398 days. This change SHOULD only apply for certification paths ending at publicly trusted CAs. But maybe Apple pushed an update that applies it across the board.
To modify the profile:
export the configuration: `ipa certprofile-show --out profile.cfg caIPAserviceCert`
edit the validity period in the profile configuration: policyset.serverCertSet.2.constraint.params.range=380
modify the profile `ipa certprofile-mod --file profile.cfg caIPAserviceCert`
On the IMAP server host use certmonger to reissue the IMAP certificate: `getcert resubmit -i 20181003215953`
Maybe that's a good idea anyway - when certificates get renewed every couple of month like letsencrypt I'll find errors in the renewal much earlier. If the renewal is manual a long validity period is useful, but when everything is automatically a short validity period is no hassle and indeed useful to catch errors early.
Jochen
OK Jochen, glad to hear it is working now. Yes, feel free to reduce the certificate validity duration. I think we should consider changing FreeIPA's default to 1 year, too.
Cheers, Fraser
On su, 06 syys 2020, Jochen Kellner via FreeIPA-users wrote:
Hello,
I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4
Today the certificate of my IMAP server (running on Debian Buster) was automatically refreshed:
,---- | Request ID '20181003215953': | status: MONITORING | stuck: no | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' | CA: IPA | issuer: CN=Certificate Authority,O=JOCHEN.ORG | subject: CN=imap.jochen.org,O=JOCHEN.ORG | expires: 2022-09-07 09:30:16 CEST | dns: imap.jochen.org | principal name: imap/jupiter.jochen.org@JOCHEN.ORG | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment | eku: id-kp-serverAuth,id-kp-clientAuth | pre-save command: | post-save command: /root/refresh_cyrus_certificate.sh | track: yes | auto-renew: yes `----
On an iPhone one of my users gets a message that the certificate is not valid. Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
When I look at the certificate with openssl I see:
,---- | X509v3 extensions: | X509v3 Authority Key Identifier: | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 | | Authority Information Access: | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp | | X509v3 Key Usage: critical | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment | X509v3 Extended Key Usage: | TLS Web Server Authentication, TLS Web Client Authentication `----
My current guess is that the "Key Usage: critical" is the reason for the iOS error.
I don't think so. Official Apple requirements state the following: https://support.apple.com/en-us/HT210176
--------------------------------------------------- All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:
- TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
- TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
- TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.
Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:
- TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
- TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
--------------------------------------------------
Can you please show both your CA and the IMAP server public certificates in their entirety?
Hello Alexander,
Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
Can you please show both your CA and the IMAP server public certificates in their entirety?
I think/hope we found the error in the iOS configuration, so I'll not send the certificates now. If I'm wrong I'll get back to the list and make sure to present the certificates. Thanks a lot for your time and your help.
Jochen
We had a developer team deploy their own CA and then issue a slew of certificates for users' workstations and other servers, and now they want us to deploy those certificates more widely. I'd rather find a way to bring their CA under ours so that the root CA certificate we already distribute will make theirs "just work" rather than having to distribute another set of root CA certificates.
Is this possible, or would they have to start over and build a subordinate CA from the ground up to make it work? If it's perhaps possible, under what circumstances?
Thanks!
Bret
On Mon, Feb 15, 2021 at 10:10:59AM -0500, Bret Wortman via FreeIPA-users wrote:
We had a developer team deploy their own CA and then issue a slew of certificates for users' workstations and other servers, and now they want us to deploy those certificates more widely. I'd rather find a way to bring their CA under ours so that the root CA certificate we already distribute will make theirs "just work" rather than having to distribute another set of root CA certificates.
Is this possible, or would they have to start over and build a subordinate CA from the ground up to make it work? If it's perhaps possible, under what circumstances?
Hi Bret,
It is possible, but there are restrictions about what the sub-CAs subject DN can be. Have a read of this blog post: https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordinat...
If your developer team's CA certificate does not fit those requirements, please share the details of the certificate (especially Subject DN) and I'll see if I can find a workaround.
Cheers, Fraser
Thanks!
Bret _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fraser,
It doesn't look like we fit the model. Our IPA CA's cert is as expected, but the other one is:
$ openssl x509 -noout -in web-ca.crt -issuer issuer= /C=US/ST=VA/L=Fairfax/O=DG Web Team/OU=DG/CN=damascusgrp.com DG Web Team Root CA
Since I don't see a hostname in there anywhere (and in fact, further conversations with this team turned up the fact that they're just creating these by hand using openssl commands rather than running any sort of service at all), I'm hesitant to just barge ahead and try to make it work on my own...
On Tue, Feb 16, 2021 at 05:53:31AM -0500, Bret Wortman wrote:
Fraser,
It doesn't look like we fit the model. Our IPA CA's cert is as expected, but the other one is:
$ openssl x509 -noout -in web-ca.crt -issuer issuer= /C=US/ST=VA/L=Fairfax/O=DG Web Team/OU=DG/CN=damascusgrp.com DG Web Team Root CA
Since I don't see a hostname in there anywhere (and in fact, further conversations with this team turned up the fact that they're just creating these by hand using openssl commands rather than running any sort of service at all), I'm hesitant to just barge ahead and try to make it work on my own...
The CN (damascusgrp.com) is a domain name. You can add a host object with that name to FreeIPA. I think the procedure outlined in the blog post should work for you.
Cheers, Fraser
-- Bret Wortman bret.wortman@damascusgrp.com
On Mon, Feb 15, 2021, at 8:30 PM, Fraser Tweedale wrote:
On Mon, Feb 15, 2021 at 10:10:59AM -0500, Bret Wortman via FreeIPA-users wrote:
We had a developer team deploy their own CA and then issue a slew of certificates for users' workstations and other servers, and now they want us to deploy those certificates more widely. I'd rather find a way to bring their CA under ours so that the root CA certificate we already distribute will make theirs "just work" rather than having to distribute another set of root CA certificates.
Is this possible, or would they have to start over and build a subordinate CA from the ground up to make it work? If it's perhaps possible, under what circumstances?
Hi Bret,
It is possible, but there are restrictions about what the sub-CAs subject DN can be. Have a read of this blog post: https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordinat...
If your developer team's CA certificate does not fit those requirements, please share the details of the certificate (especially Subject DN) and I'll see if I can find a workaround.
Cheers, Fraser
Thanks!
Bret _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Okay, I'll give it a try. Thanks!
Just to be clear, I'm going to follow the steps, but instead of setting up sub.ipa.local, I'm going to instead use simply "damascusgrp.com", yielding a principal named host/damascusgrp.com@DAMASCUSGRP.COM, right? And then proceed through the rest of the steps.
I may well have messed this up, but here's what I've done:
# ipa host-add --force damascusgrp.com ---------------------------- Added host "damascusgrp.com" ---------------------------- Host name: damascusgrp.com Principal name: host/damascusgrp.com@DAMASCUSGRP.COM Principal alias: host/damascusgrp.com@DAMASCUSGRP.COM Password: False Member of host-groups: allow_all_hosts Indirect Member of netgroup: allow_all_hosts Keytab: False Managed by: damascusgrp.com # ipa certprofile-show caIPAserviceCert --out SubCA.cfg ------------------------------------------------ Profile configuration stored in file "SubCA.cfg" ------------------------------------------------ Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE # vim SubCA.cfg : profileId=damascusgrp.com : # ipa certprofile-import 'damascusgrp.com' --desc "Web Team CA" --file SubCA.cfg --store=1 ipa: ERROR: invalid 'id': invalid Profile ID
Because the full CN is actually "damascusgrp.com DG Web Team Root CA", does that complicate this or do I just need to find a way to add all that as a host?
I found my error and got past this and completed the rest of the steps up to setting up the new server. Is there an easy way to test a certificate granted by their CA to see if it's now going to be accepted on a system where IPA's root CA certificate is present but their Root CA is not? I'd like to verify this before installing the new IPA CA for them.
On Tue, Feb 16, 2021 at 09:52:27AM -0500, Bret Wortman wrote:
I found my error and got past this and completed the rest of the steps up to setting up the new server. Is there an easy way to test a certificate granted by their CA to see if it's now going to be accepted on a system where IPA's root CA certificate is present but their Root CA is not? I'd like to verify this before installing the new IPA CA for them.
Huh, it all worked? I'm surprised it accepted the CN.
Well, you can verify the certificate chain with OpenSSL. And when you configure the server software, be sure to include the Web Team CA in the chain, otherwise there will be a missing link for clients that only have the IPA CA in their trust store.
Thanks, Fraser
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 9:23 AM, Bret Wortman wrote:
Because the full CN is actually "damascusgrp.com DG Web Team Root CA", does that complicate this or do I just need to find a way to add all that as a host?
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 8:06 AM, Bret Wortman wrote:
I may well have messed this up, but here's what I've done:
# ipa host-add --force damascusgrp.com
Added host "damascusgrp.com"
Host name: damascusgrp.com Principal name: host/damascusgrp.com@DAMASCUSGRP.COM Principal alias: host/damascusgrp.com@DAMASCUSGRP.COM Password: False Member of host-groups: allow_all_hosts Indirect Member of netgroup: allow_all_hosts Keytab: False Managed by: damascusgrp.com
# ipa certprofile-show caIPAserviceCert --out SubCA.cfg
Profile configuration stored in file "SubCA.cfg"
Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE # vim SubCA.cfg : profileId=damascusgrp.com : # ipa certprofile-import 'damascusgrp.com' --desc "Web Team CA" --file SubCA.cfg --store=1 ipa: ERROR: invalid 'id': invalid Profile ID
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 7:40 AM, Bret Wortman wrote:
Just to be clear, I'm going to follow the steps, but instead of setting up sub.ipa.local, I'm going to instead use simply "damascusgrp.com", yielding a principal named host/damascusgrp.com@DAMASCUSGRP.COM, right? And then proceed through the rest of the steps.
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 7:05 AM, Bret Wortman wrote:
Okay, I'll give it a try. Thanks!
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 6:59 AM, Fraser Tweedale wrote:
On Tue, Feb 16, 2021 at 05:53:31AM -0500, Bret Wortman wrote: > Fraser, > > It doesn't look like we fit the model. Our IPA CA's cert is as > expected, but the other one is: > > $ openssl x509 -noout -in web-ca.crt -issuer issuer= > /C=US/ST=VA/L=Fairfax/O=DG Web Team/OU=DG/CN=damascusgrp.com DG > Web Team Root CA > > Since I don't see a hostname in there anywhere (and in fact, > further conversations with this team turned up the fact that > they're just creating these by hand using openssl commands rather > than running any sort of service at all), I'm hesitant to just > barge ahead and try to make it work on my own...
The CN (damascusgrp.com) is a domain name. You can add a host object with that name to FreeIPA. I think the procedure outlined in the blog post should work for you.
Cheers, Fraser
> > -- > Bret Wortman > bret.wortman@damascusgrp.com > > On Mon, Feb 15, 2021, at 8:30 PM, Fraser Tweedale wrote: > > On Mon, Feb 15, 2021 at 10:10:59AM -0500, Bret Wortman via FreeIPA-users wrote: > > > We had a developer team deploy their own CA and then issue a slew > > > of certificates for users' workstations and other servers, and now > > > they want us to deploy those certificates more widely. I'd rather > > > find a way to bring their CA under ours so that the root CA > > > certificate we already distribute will make theirs "just work" > > > rather than having to distribute another set of root CA > > > certificates. > > > > > > Is this possible, or would they have to start over and build a > > > subordinate CA from the ground up to make it work? If it's perhaps > > > possible, under what circumstances? > > > > > Hi Bret, > > > > It is possible, but there are restrictions about what the sub-CAs > > subject DN can be. Have a read of this blog post: > > https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordinat... > > > > If your developer team's CA certificate does not fit those > > requirements, please share the details of the certificate > > (especially Subject DN) and I'll see if I can find a workaround. > > > > Cheers, > > Fraser > > > > > > > > Thanks! > > > > > > Bret > > > _______________________________________________ > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... > > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > > > >
On Tue, Feb 16, 2021 at 09:23:23AM -0500, Bret Wortman wrote:
Because the full CN is actually "damascusgrp.com DG Web Team Root CA", does that complicate this or do I just need to find a way to add all that as a host?
I'm sorry. Yes it does. I misread the DN! My apologies.
I will think about what workaround may be possible for you.
One that immediately comes to mind is make an intermediate CA with OpenSSL, that has a domain name as CN. Sign the Web Team CA with the intermediate, then sign the intermediate with FreeIPA.
But I'll see if I can think of any other approach.
As for the "Invalid profile ID" error, it is due to the "." character in "damascusgrp.com". Just replace it with an underscore in the profileID.
Thanks, Fraser
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 8:06 AM, Bret Wortman wrote:
I may well have messed this up, but here's what I've done:
# ipa host-add --force damascusgrp.com
Added host "damascusgrp.com"
Host name: damascusgrp.com Principal name: host/damascusgrp.com@DAMASCUSGRP.COM Principal alias: host/damascusgrp.com@DAMASCUSGRP.COM Password: False Member of host-groups: allow_all_hosts Indirect Member of netgroup: allow_all_hosts Keytab: False Managed by: damascusgrp.com
# ipa certprofile-show caIPAserviceCert --out SubCA.cfg
Profile configuration stored in file "SubCA.cfg"
Profile ID: caIPAserviceCert Profile description: Standard profile for network services Store issued certificates: TRUE # vim SubCA.cfg : profileId=damascusgrp.com : # ipa certprofile-import 'damascusgrp.com' --desc "Web Team CA" --file SubCA.cfg --store=1 ipa: ERROR: invalid 'id': invalid Profile ID
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 7:40 AM, Bret Wortman wrote:
Just to be clear, I'm going to follow the steps, but instead of setting up sub.ipa.local, I'm going to instead use simply "damascusgrp.com", yielding a principal named host/damascusgrp.com@DAMASCUSGRP.COM, right? And then proceed through the rest of the steps.
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 7:05 AM, Bret Wortman wrote:
Okay, I'll give it a try. Thanks!
-- Bret Wortman bret.wortman@damascusgrp.com
On Tue, Feb 16, 2021, at 6:59 AM, Fraser Tweedale wrote:
On Tue, Feb 16, 2021 at 05:53:31AM -0500, Bret Wortman wrote:
Fraser,
It doesn't look like we fit the model. Our IPA CA's cert is as expected, but the other one is:
$ openssl x509 -noout -in web-ca.crt -issuer issuer= /C=US/ST=VA/L=Fairfax/O=DG Web Team/OU=DG/CN=damascusgrp.com DG Web Team Root CA
Since I don't see a hostname in there anywhere (and in fact, further conversations with this team turned up the fact that they're just creating these by hand using openssl commands rather than running any sort of service at all), I'm hesitant to just barge ahead and try to make it work on my own...
The CN (damascusgrp.com) is a domain name. You can add a host object with that name to FreeIPA. I think the procedure outlined in the blog post should work for you.
Cheers, Fraser
-- Bret Wortman bret.wortman@damascusgrp.com
On Mon, Feb 15, 2021, at 8:30 PM, Fraser Tweedale wrote: > On Mon, Feb 15, 2021 at 10:10:59AM -0500, Bret Wortman via FreeIPA-users wrote: > > We had a developer team deploy their own CA and then issue a slew > > of certificates for users' workstations and other servers, and now > > they want us to deploy those certificates more widely. I'd rather > > find a way to bring their CA under ours so that the root CA > > certificate we already distribute will make theirs "just work" > > rather than having to distribute another set of root CA > > certificates. > > > > Is this possible, or would they have to start over and build a > > subordinate CA from the ground up to make it work? If it's perhaps > > possible, under what circumstances? > > > Hi Bret, > > It is possible, but there are restrictions about what the sub-CAs > subject DN can be. Have a read of this blog post: > https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordinat... > > If your developer team's CA certificate does not fit those > requirements, please share the details of the certificate > (especially Subject DN) and I'll see if I can find a workaround. > > Cheers, > Fraser > > > > > Thanks! > > > > Bret > > _______________________________________________ > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > >
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Bret Wortman -
Fraser Tweedale -
Jochen Kellner