Hello,
I'd like to ask of is there any workaround for issuing certificates that will have Common Name longer that 64 characters?
For FREEIPA version less than 4.8.0 which is designated for RHEL 8, when we will have to stay with current version of RHEL 7.
Regards, Krzysztof
Krzysztof O via FreeIPA-users wrote:
Hello,
I'd like to ask of is there any workaround for issuing certificates that will have Common Name longer that 64 characters?
For FREEIPA version less than 4.8.0 which is designated for RHEL 8, when we will have to stay with current version of RHEL 7.
RFC 3280 defines the upper-bound of common name at 64 and is mandatory.
What problem is this causing?
rob
Krzysztof O via FreeIPA-users wrote:
RFC 3280 defines the upper-bound of common name at 64 and is mandatory.
What problem is this causing?
rob
When issuing CSR from the overcloud nodes, the CN field value exceeds the 64 characters limit and the request fails. We expect to be able to issue CSRs for FQDNs longer than 64 characters.
The domain cannot be shortened, at least the customer subdomain so we need a solution which will allow us to deploy a RHOSP cluster with TLS everywhere enabled, when the FQDN used in CN is longer than 64 characters.
"Warning: Could not get certificate: Execution of '/usr/bin/getcert request -I libvirt-server-cert -f /etc/pki/libvirt/servercert.pem -c IPA -N CN=[longer_than_64_chars] -K libvirt/host -D host -C systemctl reload libvirtd -w -k /etc/pki/libvirt/private/serverkey.pem' returned 3: New signing request "libvirt-server-cert" added.", "Error: /Stage[main]/Tripleo::Profile::Base::Certmonger_user/Tripleo::Certmonger::Libvirt[libvirt-server-cert]/Certmonger_certificate[libvirt-server-cert]: Could not evaluate: Could not get certificate: Server at https://ipa_host/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Invalid Subject Name CN=cn_longer_than_64_chars,O=organization_name [ Invalid fields: Common Name ] ).",
(I've hidden real CN and host names)
On 19/10/2020 15.17, Krzysztof O via FreeIPA-users wrote:
Krzysztof O via FreeIPA-users wrote:
RFC 3280 defines the upper-bound of common name at 64 and is mandatory.
What problem is this causing?
rob
When issuing CSR from the overcloud nodes, the CN field value exceeds the 64 characters limit and the request fails. We expect to be able to issue CSRs for FQDNs longer than 64 characters.
The domain cannot be shortened, at least the customer subdomain so we need a solution which will allow us to deploy a RHOSP cluster with TLS everywhere enabled, when the FQDN used in CN is longer than 64 characters.
This is not possible. RFC 3280 limits the upper bound for common name to 64 octets. From https://tools.ietf.org/html/rfc3280#appendix-A.1 page 103:
ub-common-name INTEGER ::= 64
A certificate with a longer common name would be in violation of the standard and therefore an invalid certificate.
In general hostnames with more than 64 octets are badly supported by Linux kernel. For example gethostname() and uname()'s utsname->nodename are limited to 64 characters. You are going to run into more issues.
Christian
On ma, 19 loka 2020, Christian Heimes via FreeIPA-users wrote:
On 19/10/2020 15.17, Krzysztof O via FreeIPA-users wrote:
Krzysztof O via FreeIPA-users wrote:
RFC 3280 defines the upper-bound of common name at 64 and is mandatory.
What problem is this causing?
rob
When issuing CSR from the overcloud nodes, the CN field value exceeds the 64 characters limit and the request fails. We expect to be able to issue CSRs for FQDNs longer than 64 characters.
The domain cannot be shortened, at least the customer subdomain so we need a solution which will allow us to deploy a RHOSP cluster with TLS everywhere enabled, when the FQDN used in CN is longer than 64 characters.
This is not possible. RFC 3280 limits the upper bound for common name to 64 octets. From https://tools.ietf.org/html/rfc3280#appendix-A.1 page 103:
ub-common-name INTEGER ::= 64
A certificate with a longer common name would be in violation of the standard and therefore an invalid certificate.
In general hostnames with more than 64 octets are badly supported by Linux kernel. For example gethostname() and uname()'s utsname->nodename are limited to 64 characters. You are going to run into more issues.
Also, if this is about TLS certificates, contemporary clients should be looking into dNSName SAN values, not CN. So the solution would be to explicitly populate those names and make sure IPA grants issuance rights to those.
On Mon, Oct 19, 2020 at 06:52:20AM -0000, Krzysztof O via FreeIPA-users wrote:
Hello,
I'd like to ask of is there any workaround for issuing certificates that will have Common Name longer that 64 characters?
For FREEIPA version less than 4.8.0 which is designated for RHEL 8, when we will have to stay with current version of RHEL 7.
Regards, Krzysztof
Hi Krzysztof,
X.509 imposes the limit of 64 characters in the Common Name attribute. There is no workaround to exceed this limit. But assuming this is a host or service certificate bearing DNS names, you can work around it another way:
Add a principal alias to the host/service entry via `ipa {host,service}-add-principal command. The principal alias should have the same service type as the main object, i.e. "host/$HOSTNAME" for a host princpal, "HTTP/$HOSTNAME" for a HTTP service principal, etc. The hostname in the principal alias should be shorter than 64 characters.
Create a CSR with the shorter hostname in the CN attribute, and the longer hostname in the SAN DNS name. Then you will be able to request the certificate.
The proper solution would be to support issuing certificates with empty subject DN. I thought I previously filed a ticket for this, but I can't find it now.
Cheers, Fraser
On Mon, Oct 19, 2020 at 11:42:08PM +1000, Fraser Tweedale via FreeIPA-users wrote:
On Mon, Oct 19, 2020 at 06:52:20AM -0000, Krzysztof O via FreeIPA-users wrote:
Hello,
I'd like to ask of is there any workaround for issuing certificates that will have Common Name longer that 64 characters?
For FREEIPA version less than 4.8.0 which is designated for RHEL 8, when we will have to stay with current version of RHEL 7.
Regards, Krzysztof
Hi Krzysztof,
X.509 imposes the limit of 64 characters in the Common Name attribute. There is no workaround to exceed this limit. But assuming this is a host or service certificate bearing DNS names, you can work around it another way:
Add a principal alias to the host/service entry via `ipa {host,service}-add-principal command. The principal alias should have the same service type as the main object, i.e. "host/$HOSTNAME" for a host princpal, "HTTP/$HOSTNAME" for a HTTP service principal, etc. The hostname in the principal alias should be shorter than 64 characters.
Create a CSR with the shorter hostname in the CN attribute, and the longer hostname in the SAN DNS name. Then you will be able to request the certificate.
The proper solution would be to support issuing certificates with empty subject DN. I thought I previously filed a ticket for this, but I can't find it now.
Found the ticket: https://pagure.io/freeipa/issue/5706
I also wrote a blog post about this, detailing the workaround procedure: https://frasertweedale.github.io/blog-redhat/posts/2020-10-20-ipa-cert-long-...
Cheers, Fraser
On Mon, Oct 19, 2020 at 11:42:08PM +1000, Fraser Tweedale via FreeIPA-users wrote: Found the ticket: https://pagure.io/freeipa/issue/5706
I also wrote a blog post about this, detailing the workaround procedure: https://frasertweedale.github.io/blog-redhat/posts/2020-10-20-ipa-cert-lo...
Cheers, Fraser
Thank you Fraser for the article. We will check with Red Hat if we would upgrade to version RHEL 8/ipa 4.8.0 to resolve the issue. Upgrading from version 7 in cluster would cause a lot of issues.
We will have in minds those workarounds :)
Cheers, Krzysztof
On Wed, Oct 21, 2020 at 07:21:21AM -0000, Krzysztof O via FreeIPA-users wrote:
On Mon, Oct 19, 2020 at 11:42:08PM +1000, Fraser Tweedale via FreeIPA-users wrote: Found the ticket: https://pagure.io/freeipa/issue/5706
I also wrote a blog post about this, detailing the workaround procedure: https://frasertweedale.github.io/blog-redhat/posts/2020-10-20-ipa-cert-lo...
Cheers, Fraser
Thank you Fraser for the article. We will check with Red Hat if we would upgrade to version RHEL 8/ipa 4.8.0 to resolve the issue. Upgrading from version 7 in cluster would cause a lot of issues.
We will have in minds those workarounds :)
Hi Krzysztof,
Upgrading to RHEL 8 will not make the 64 char limit go away. So no need to rush into that. The only** workaround I know of is the one I documented.
** OK there is another; it takes a similar but more complicated approach so I do not bother talking about it :)
Cheers, Fraser
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Christian Heimes -
Fraser Tweedale -
Krzysztof O -
Rob Crittenden