Underscore in subdomain fails

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:
./certbot-auto certonly -a webroot --webroot-path=/var/www/server/hugform_rng/cms --renew-by-default --email technik@komtrigon.de --text --agree-tos -d edge.ioi.hugform_rng.komtrigon.de

It produced this output:
Obtaining a new certificate
An unexpected error occurred:
The request message was malformed :: Invalid character in DNS name
Please see the logfiles in /var/log/letsencrypt for more details.

My operating system is (include version):
SMP Debian 3.2.68-1+deb7u2

My web server is (include version):

My hosting provider, if applicable, is:
Host Europe

I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

With ticket https://github.com/letsencrypt/boulder/pull/1437 Support for underscores in subdomains is added.

Debug out:
2017-04-05 13:51:08,221:DEBUG:acme.client:JWS payload:
“identifier”: {
“type”: “dns”,
“value”: “edge.ioi.hugform_rng.komtrigon.de”
“resource”: “new-authz”

Hi @rbraband,

The issue you linked to here has your explanation:

RFC 952 and 1123 outline that the safe hostname character set is [a-zA-Z0-9-] (with special rules about where hypens can appear). While certain DNS RR types (DomainKeys and SRV) are allowed to use underscores in record names these are not valid hostnames.

Let’s Encrypt follows the two RFCs listed above and we do not allow underscores in hostnames. You won’t be able to issue a Let’s Encrypt certificate for “edge.ioi.hugform_rng.komtrigon.de” without changing the DNS record to not include the _ character.

1 Like

Hi @cpu,
thank you for explanation. And sorry for my bad english :wink:

So I copy here a good explanation of what I think from https://en.wikipedia.org/wiki/Hostname

Ok, I think we have a problem with different description of what we have here - a hostname or a DNS domain name.

Hostnames are human-readable nicknames that correspond to the address of a device connected to a network. They are used by various naming systems, e.g., Network Information Service (NIS), Domain Name System (DNS), Server Message Block (SMB) and the meaning of hostname varies according to the naming system used.

Hostnames are typically used in an administrative capacity and may appear in computer browser lists, active directory lists, IP address to hostname resolutions, email headers, etc.

On the Internet, a hostname is a domain name assigned to a host computer. This is usually a combination of the host’s local name with its parent domain’s name. For example, en.wikipedia.org consists of a local hostname (en) and the domain name wikipedia.org. This kind of hostname is translated into an IP address via the local hosts file, or the Domain Name System (DNS) resolver. It is possible for a single host computer to have several hostnames; but generally the operating system of the host prefers to have one hostname that the host uses for itself.

Any domain name can also be a hostname, as long as the restrictions mentioned below are followed. So, for example, both en.wikipedia.org and wikipedia.org are hostnames because they both have IP addresses assigned to them. The domain name pmtpa.wikimedia.org is not a hostname since it does not have an IP address (as of now), but rr.pmtpa.wikimedia.org is a hostname. A hostname may be a domain name, if it is properly organized into the domain name system. A domain name may be a hostname if it has been assigned to an Internet host and associated with the host’s IP address.

What I will say is that you actual say that you only support hostnames but in the real world we use DNS - Not least I want to create a certificate for a domain name and use it on the internet - Huh !1!!

Let me quote the standard, RFC 2181, section 11, “Name syntax”:

The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. […] Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.

See also the original DNS specification, RFC 1034, section 3.5 “Preferred name syntax” but read it carefully.

Domains with underscores are very common in the wild. Check _jabber._tcp.gmail.com or _sip._udp.apnic.net.

Other RFC mentioned here deal with different things. The original question was for domain names. If the question is for host names (or for URLs, which include a host name), then this is different, the relevant standard is RFC 1123, section 2.1 “Host Names and Numbers” which limits host names to letters-digits-hyphen.

Ok now - Can you support DNS domain names or wants letsencrypt to restrict itself to hostnames?


I apologize now when I am totally wrong

Let’s Encrypt wants to restrict itself to issuing certificates for hostnames. The CA is very well aware that DNS labels can contain underscores; the ACME DNS-01 verification method specifically requires underscores in DNS names used for verification of domain control and so Let’s Encrypt regularly requires that people requesting certificates create DNS RRs beginning with underscores for this purpose. However, Let’s Encrypt is only willing to issue certificates for subject names that are hostnames.

1 Like

Thank you for clarification.

Roland Braband

To add a little more detail: Let’s Encrypt is required to abide by the terms of various root programs.

Those root programs all require participating CAs to follow the CA/Browser Forum Baseline Requirements.

The Baseline Requirements, in turn, require certificates to be in accordance with RFC 5280.

RFC 5280 requires that subjectAltNames be in the “preferred name syntax” from RFC 1034.

RFC 1034’s “preferred name syntax” requires labels to contain only letters, digits, and hyphens.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.