PSA: Change in Firefox related to host names and its impact on IPA

[Rob Crittenden]

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