Newer python urllib3 is now spewing a warning regarding non-use of SAN:

/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no subjectAltName, falling back to check for a commonName for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)

I don't know if this can be handled directly in the profile or whether we need to have certmonger always include a SAN in its request.

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1200694 (Red Hat Enterprise Linux 7)

Work for the default profiles, assigning to Fraser.

This is a nontrival fix for a couple of reasons:

1) caIPAserviceCert profile supports SAN extension via CSR extensionRequest.
cert-request checks that the names make sense (e.g. dNSName values
correspond to existing host/service objects), then the UserExtensionDefault
profile default copies the SAN extension to the certificate verbatim.

This ticket is asking us to put the CN in the SAN; it can be done easily
with the following profile config snippet:

policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.12.default.name=Subject Alternative Name Extension Default
policyset.serverCertSet.12.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.12.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.12.default.params.subjAltExtPattern_0=$request.req_subject_name.cn$

BUT if the CSR has a SAN extensionRequest this will fail due to duplicate extension.

What is really needed is a profile default that copies names from CSR SAN ext and
adds a dNSName corresponding to the CN if it was not in the CSR SAN ext.

2) Now that we support user certs, the CN will not always be a dNSName.
To deal with this we could:

• make a naive guess that a CN that looks like a hostname is a hostname and add it to SAN as a dNSName, and not add it otherwise.
• for caIPAserviceCert profile and other profiles for hosts/services, just copy the CN to SAN as dNSName and expect that in other cases, a different profile with different configuration will be used.

Whatever we do, the solution will mainly be in Dogtag, and will probably require
and update to the caIPAserviceCert profile to switch to the new behaviour.

I've reported a similar issue in Dogtag because I saw the same warning in Python requests: https://fedorahosted.org/pki/ticket/1464

Given it is very late for 4.2 release, we need to postpone this to next feature release.

PKI ticket https://fedorahosted.org/pki/ticket/1710 will add profile
component that copies CN to dNSName altname. After that is done
this ticket requires:

• update specfile to depend on new version of pki
• update caIPAserviceCert profile

Updating milestone and priority to match #5523 which was closed
as duplicate of this ticket.

See also:

• 5706 ([RFE] Support SAN-only certificates)

• 5707 ([RFE] Warn if CN length is 64-octets)

4.4.0 was released, moving open tickets to 4.4.1

master:

• b12db92 Create server and host certs with DNS altname

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1358457 (Red Hat Enterprise Linux 7)

It needs more work. Which won't be done in 4.4. Moving to 4.5 and resetting priority - should be set after 4.5 triage.

I'm bumping up the priority to blocker and setting version to 4.5.0. Recently Firefox and Chrome have tighten validation for certificates. For public CA in the CA/Browser forum, SAN DNS names are now mandatory and Subject CN is ignored. Python requests has been warning about subjects w/o SAN for some time, too. Sooner or later I expect all libraries and browsers to require correct SAN.

Since it is going to take a while to migrate and re-issue all certificates to SAN certs, we should implement mandatory and default SAN extensions for TLS server certs ASAP.

In the mean time bug https://bugzilla.redhat.com/show_bug.cgi?id=1400293 is causing trouble for Firefox on Fedora. If I understand the issue correctly, Firefox considers IPA's root CA as CA/B cert because it is provided by the system CA provider, https://bugzilla.mozilla.org/show_bug.cgi?id=1324096. Kai is working on a fix.

Even though I agree with ASAP fix and blocker, it should go trough triage. We might actaully consider 4.4.4 milestone.

Petr, good point!

Fraser, does Dogtag PKI from FreeIPA 4.4 support the necessary operations to copy subject CN to SAN? I vaguely remember that you worked on some profile-related enhancements. FreeIPA 4.4.3 has pki-ca >= 10.3.5-6.

Petr, Christian: the new profile components are not implemented yet. It's very
tricky to introduce (and use) new profile components because not all CA servers in
the topology will necessarily be upgraded at the same time.

That said, we will (very likely) be having a Domain Level bump for Dogtag->GSS-API
authentication so this is the best time to add other new profile components.

In the meantime, we just need to educate that CSRs contain SAN or, perhaps better,
validate that they do and provide useful error messages if they do not. It could be
configured on a per-profile basis, as IPA-only configuration (i.e. Dogtag would not
need to know about it).

Per triage, this is not for 4.5 release. But cert-request should warn is CSR doesn't contain SAN - #6663

Note that the required Dogtag component (https://fedorahosted.org/pki/ticket/1710)
is merged and will be released with Dogtag 10.4.

As per Chrome v58 (released 19/04/2017) certificate checking is done based on subjectAltName instead of commonName. This means that certificates are marked as invalid due to loss of support. Can the priority on this issue be raised (from future release to 4.5) since this affects the core functionality of FreeIPA.

See also sub-ticket https://pagure.io/freeipa/issue/7007

The issue was fixed on pki side with https://pagure.io/dogtagpki/issue/2995
The fix is available in pki 10.6.2+ or pki 10.5.8+.

Currently the ipa-4-7 and master branches of FreeIPA requires pki 10.6.6, hence we can close this issue.

I OK with this being closed (read on) but allow me to clarify why it was still open:

This ticket was still open because we do not yet have a profile update
mechanism that would let us upgrade older versions of FreeIPA to add the
CommonNameToSANDefault profile component, when the whole topology is
on a version that contains that component. This work will still need to be done
to finish the IPA->Dogtag GSSAPI authentication story. There is a separate ticket
(https://pagure.io/freeipa/issue/5323) and design proposal (https://www.freeipa.org/page/V4/Certificate_profile_update_mechanism) for this work.

Nevertheless, as time goes by the importance of the profile upgrade for the SAN
component decreases, because newer installations have it by default and older
installations can be (and many probably have been) manually updated. So I'm
OK with leaving this closed.