[cabfpub] Underscore Characters in SANs

Phillip Hallam-Baker philliph at comodo.com
Mon Aug 12 16:53:40 UTC 2013


Actually this is best practice.

The underscore character is used as a means of extending the DNS name system. The DNS SRV (service) record started this practice. http.example.com could be a legitimate domain name. So to unambiguously specify the http service of example.com they used _http instead, actually _http._tcp.


These names are fully routable. The only thing that is advised against is delegating an underscore name or putting an A record there.


On Aug 12, 2013, at 2:22 PM, "Robin Alden" <robin at comodo.com> wrote:

> Hi Wayne,
>                 I don’t think there’s a need for us (CAs) to ban the use of underscores in dnsNames in certificates.
>  
> Comodo has issued certificates including RFC2782 format names, e.g.:
> _sip._tls.xxxxxxx.com
>  
> We have also issued certificates including dnsNames which are probably not (intended to be) internet routable, such as:
> m_staging9.xxxxxxx.com
>  
> In both cases the certificates can be validated using the usual automated DCV process for xxxxxxx.com
>  
> I have to say the numbers of such certificates we see is vanishingly small.
>  
> Regards
> Robin
>  
>  
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer
> Sent: 07 August 2013 17:45
> To: Erwann Abalea; public at cabforum.org
> Subject: Re: [cabfpub] Underscore Characters in SANs
>  
> Erwann,
>  
> I’m specifically talking about a CNAME record. In researching this, it appears that DKIM specifies underscore characters in CNAMEs, but it may refer to an updated RFC rather than 1035 in doing so.  The DKIM spec has in turn driven major DNS providers to start allowing the underscore character in CNAMEs. I have a few examples of this. So I’m wondering if there’s any reason in practice not to issue certificates with SANs containing this character, other than the fact that it’s probably not compatible with some browsers that expect a proper host name?
>  
> Thanks,
>  
> Wayne
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Erwann Abalea
> Sent: Wednesday, August 07, 2013 2:22 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Underscore Characters in SANs
>  
> Taken from X.509: "dNSName is an Internet domain name defined in accordance with Internet RFC 1035."
> 
> So far, IIRC, the only possible DNS entries that support the underscore character are of type TXT and SRV. A, AAAA, CNAME, NS, MX records can't use such a character.
> Refering to a TXT entry is useless in a SAN, refering to a SRV entry may have a meaning (this needs to be discussed). But in that case, the entry MUST follow RFC2782 format ("_Service._Proto.Name", for example "_xmpp._tcp.godaddy.com").
> 
> Even in such a case, you'll have a DNS entry such as this one:
> _xmpp._tcp.godaddy.com. IN SRV 0 1 5222 chat.godaddy.com.
> and the certificate would certainly be delivered to "chat.godaddy.com".
> 
> 
> -- 
> Erwann ABALEA
>  
> Le 07/08/2013 06:47, Wayne Thayer a écrit :
> Can anyone tell me if there is a reason not to allow an underscore (_) character in a DNSName SAN field?  From what I can tell, a DNSName can contain this character, and I can do DNS queries that return public FQDNs in the format "a_b.domain.tld".  A host name does not permit this character, so it may not work properly in a browser, but from what I can tell, some other type of service using SSL should be able to leverage an SSL certificate with this character in the SAN.
>  
> Thanks,
>  
> Wayne
>  
> 
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>  
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130812/45b274b9/attachment-0003.html>


More information about the Public mailing list