Hello,
thanks for your suggestions, I'll answer below. TL;DR: seems to work now.
Fraser Tweedale via FreeIPA-users <freeipa-users(a)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(a)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.