jcholast mentioned:
I would also be wary of 64 octet CNs - they might contain an actual 64 octet host name, but they might as well contain a host name truncated to 64 octets, and there is no way to differentiate between the two cases.
It was agreed that the cert-request command should emit a warning when the CN length is 64, because of the possibility that it was truncated from a longer input when producing the CSR (hostnames longer than 64 octets are common in cloud environments; see #4415 for example).
Link to RFC 5280 where it defines the upper bounds: https://tools.ietf.org/html/rfc5280#page-124
we have following checks in code:
cn = subject.common_name ... if cn.lower() != principal_name.lower(): raise errors.ACIError( info=_("hostname in subject of request '%(cn)s' " "does not match principal hostname '%(hostname)s'") % dict(cn=cn, hostname=principal_name))
if CN is truncated, then it will not match principal, so it will fail anyway.
Or am I missing something?
mbasti: this is true in current code, but due to #5706 this check will be replaced with one where the union of CN (if present) and all SAN dnsNames are checked for a match. Even then the CN must still match a known principal, but what if one long CN, truncated to 64 chars, happens to match some principal.
IMO given this edge case it is will worth warning about it.
4.4.0 was released, moving open tickets to 4.4.1
moving out tickets not implemented in 4.4.1
4.4.2 is a stabilization milestone. If this bug is important stabilization bug then please put it to NEEDS TRIAGE milestone for retriage.
Metadata Update from @ftweedal: - Issue assigned to mbasti - Issue set to the milestone: FreeIPA 4.5 backlog
Metadata Update from @mbasti: - Assignee reset
Login to comment on this ticket.