Heads up about a change in Firefox v101.0 that can affect some deployments of freeIPA.
https://www.mozilla.org/en-US/firefox/101.0/releasenotes reads:
"Removed "subject common name" fallback support from certificate validation. This fallback mode was previously enabled only for manually installed certificates. The CA Browser Forum Baseline Requirements have required the presence of the "subjectAltName" extension since 2012, and use of the subject common name was deprecated in RFC 2818."
This has been a long time coming. RFC2818 contains this:
https://datatracker.ietf.org/doc/html/rfc2818#section-3.1
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
It is probably a safe assumption that other browsers will soon follow suit.
If you don't use the IPA CA then you need to verify that the certificates, from Let's Encrypt for example, contain a DNS Subject Alternative Name (SAN) (LE should already). If not then you need to work with the provider(s) to reissue new ones.
Installations with an IPA CA has enabled a DNS SAN for the Apache and 389 certificates since 4.5.1 so newer deployments should be unaffected by this.
To confirm that the current IPA-issued certificates, including an IPA CA signed as a subordinate by an external CA, contain a SAN:
For IPA 4.6 and earlier:
# getcert list -d /etc/httpd/alias -n Server-Cert # getcert list -d /etc/dirsrv/slapd-<REALM> -n Server-Cert
For IPA 4.7 and later:
# getcert list -f /var/lib/ipa/certs/httpd.crt # getcert list -d /etc/dirsrv/slapd-<REALM> -n Server-Cert
Included in the output for each cert should be a line like:
dns: ipa.example.test
Where ipa.example.test is the hostname of the machine.
If it isn't you can use certmonger to add a DNS SAN and reissue an existing certificate with:
# getcert resubmit -i <certmonger_request_id> -D $(hostname)
If you aren't using an IPA CA then it is still possible to verify but it is slightly more complicated because the certificate nickname(s) may be different.
For IPA 4.6 and earlier:
# grep NSSNickname /etc/httpd/conf.d/nss.conf # certutil -L -d /etc/httpd/alias -n "<the value from above>"
# grep nsSSLPersonalitySSL /etc/dirsrv/slapd-REALM/dse.ldif # certutil -L -d /etc/dirsrv/slapd-REALM -n "<the value from above>"
The output for each should contain something like:
Name: Certificate Subject Alt Name DNS name: "ipa.example.test"
Where ipa.example.test is the hostname of the machine.
For IPA 4.7 and later:
# grep SSLCertificateFile /etc/httpd/conf.d/ssl.conf # openssl x509 -noout -text -in "<the value from above>"
The output should contain something like:
X509v3 Subject Alternative Name: DNS:ipa.example.test
# grep nsSSLPersonalitySSL /etc/dirsrv/slapd-REALM/dse.ldif # certutil -L -d /etc/dirsrv/slapd-REALM -n "<the value from above>"
The output for each should contain something like:
Name: Certificate Subject Alt Name DNS name: "ipa.example.test"
Where ipa.example.test is the hostname of the machine.
If not you'll need to contact the issuing CA to get a replacement with a DNS SAN.
rob
freeipa-users@lists.fedorahosted.org