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....@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: >> >> 1. 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. >> 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? >> > I think the profile configuration is fine. Thanks for the confirmation. >> 3. 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` 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 -- This space is intentionally left blank. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
