Does certbot work with "SNI" or Server Name Indication?

I want to know if it is possible or preferable to have seperate certificates rather than listing all domains on the same certificate on one web server. Is it supported by most web servers?

See https://www.cloudflare.com/learning/ssl/what-is-sni/
Also Welcome to certbot-dns-cloudflare’s documentation! — certbot-dns-cloudflare 0 documentation

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: amarillo.colmena.biz, ellipticcurve.info, lindberg.farm

I ran this command: sleep $RANDOM && /usr/bin/certbot renew

It produced this output: the usual

My web server is (include version):nginx.x86_64 1:1.16.1-3.el7 @epel

The operating system my web server runs on is (include version): CentOS 7

My hosting provider, if applicable, is: Hostinger / Cloudflare

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.11.0

1 Like

Yes, certainly.

You can set up separate certificates by virtualhost, e.g.:

sudo certbot --nginx -d lindberg.farm -d www.lindberg.farm
sudo certbot --nginx -d ellipticcurve.info -d www.ellipticcurve.info

and so on.

1 Like

So if I do that, is it safe to remove the extra domains from the "default" server certificate for the canonical hostname "amarillo.colmena.biz" which I am also using for postfix to accept "STARTTLS" connections for email encryption and possibly other purposes?

Or will the client web browser fail to connect if those domains are not listed on the certificate initially presented?

And what about DANE? Since I have already enabled DNSSEC on all my domains with Cloudlfare, my next question in that regard is, "Can Certbot with the 'cloudflare' or other provider plugins be configured to use so-called DNS-Based Authentication of Named Entities rather than the letsencrypt.org x.509 CA as a certificate authority?"
What is DANE? | Infoblox DNS Security Center FAQ
RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA

1 Like

Generally yes.

No, the SNI step happens even before a certificate is presented (in the TLS ClientHello message, which is the very first step of all in the connection), so your server can choose the appropriate certificate.

Certbot is purely an X.509 certificate client. While it can use several different compatible CAs to request certificates, it can't be made to do something other than requesting a certificate from a CA.

You can use the --deploy-hook option to do something else additional after a certificate has been obtained, which could potentially include creating and publishing DANE records based on the content of the new certificate. The Certbot Cloudflare plugin isn't relevant or helpful for this, because the Certbot DNS plugin architecture is only aimed at creating TXT records to satisfy ACME proof-of-domain-control challenges, before a certificate is issued, and not for any other purpose.

In principle, DANE could be a complete alternative to a certificate, but no major browser uses it this way. (I think possibly some e-mail software does, or can be configured to.) So if you decided to use DANE instead of a certificate, you would lose compatibility with mainstream browsers: none of them accept it as a substitute!

1 Like

I "assume" it would be possible to do that -- I can't imagine why not -- even alongside existing x.509 authentication. If a DNS-secured DANE record exists or is published matching any given server certificate, it should be possible for that to serve as strong authentication for the certificate on the authority of the DNSSEC architecture itself, alongside of and independent of any given x.509 CA.

1 Like

I agree! We just haven't seen many software implementers decide to extend trust via this mechanism.

My impression is that it remains pretty controversial, as quite a number of people from the e-mail operator world prefer DANE+DNSSEC to the existing web PKI, while quite a number of people from the web world don't, and those people haven't really ever come to a consensus over this, though not for lack of debating it.

1 Like

FWIW

One reason why browser developers have not been as enthusiastic about DANE is deployability. Unfortunately many DNS servers (especially commercial DNS servers) do not implement the specification properly. They answer the simplest type of query (A? used to find out the IP address corresponding to a name) but they often get other queries wrong in critical ways. For DNSSEC, and thus DANE, this is an obstacle. It's a problem for Let's Encrypt itself of course too due to the CAA requirement. For Let's Encrypt this means on this forum sometimes we have to patiently explain to people that their network setup is faulty and they need to fix it before we can help them.

But for DANE the problem hits the end user, who may have no power to change anything, so if browsers embraced DANE there's a risk some users would just no longer be able to access much of the Internet.

Over the next few years we can expect to see increased take up of DPRIVE technologies such as DNS over TLS, DNS over HTTPS, and DNS over QUIC. Both the technologies themselves (by knocking out "passive" surveillance or censorship systems which interfere with DNS queries) and the contracts put in place by vendors like Mozilla and Google to authorise the public resolvers for these technologies, get us to a place where we can deploy more DNS-based technologies. As a result it may become practical to use DANE some time in the next decade. Or maybe not.

1 Like

That's a common issue with CDNs and DDoS prevention technologies.

Add to that the various tradeoffs between absolute "end-to-end" security and the possibility of serving cached or cacheable static content over https without overloading the originating server.

And the need to be creative with certain technologies in order to "duck around the corner" from various DDoS attacks on mission-critical ports.

I'm new to much of this stuff, and I fully realize not all "commercial grade" implementations are fully in compliance with educational or RFC technical standards.

1 Like

So if I do that, do the virtual domains still have to be included on the
certificate initially presented by the server on connections to port 443?
Or can they be deleted from that certificate without any ill effects?

At present, I am also using Cloudflare for DNS and caching / content
distribution. The caching proxy servers "in the cloud" obviously have their
own certificates from a different CA, so I added another CAA record to
authorize that CA for the use of my domains with their services.

This all "works" with DNSSEC enabled, which rather amazes me. It's a "CDN"
("Content Distribution Network") or "Traffic Shaping" architecture rather than
a true end-to-end encryption for everything on a "Network Neutrality" basis
which would require bigger VPS servers.

1 Like

I think you're experiencing a misunderstanding about how SNI works.

The very first message sent by a client, the ClientHello, includes this Server Name Indication. As a result the server gets to decide everything after knowing which name is requested. It gets to send only the certificate configured for that name, it can even (though you generally wouldn't want to do this) choose completely different cryptography for different names.

So the certificate "initially" presented, is the only one presented at all, and your server software's virtual domain configuration should ensure that's the appropriate certificate for the name requested.

2 Likes

There is a proposal to change this

https://tools.ietf.org/id/draft-ietf-tls-esni-08.html

so that the ClientHello could itself be encrypted and servers could have another layer of keys and TLS and DNS configuration to deal with this. But while this is really cool, it would probably mostly be used by CDNs in practice, and it would be deployed in a backwards-compatible way so that servers wouldn't be required to support it.

You really need "GREASE extensions" for something that simple? That almost
sounds a little bit low-class to me, almost like the "HSTS" which has
alternate significations.

https://tools.ietf.org/id/draft-ietf-tls-esni-08.html#name-grease-extensions
https://www.rfc-editor.org/info/rfc8701

Almost like there's a locksmith shop or two in town, and we just gotta have
that little something extra to lubricate the https padlocks. Perhaps a little
bit more critical assessment of some of these RFCs ("Requests For Comment") is
in order before immediately implementing them as federal law by fiat.

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