I saw some people use “–preferred-challenges tls-sni-01” and some “–preferred-challenges tls-sni”, and the official document says this:
- –preferred-challenges http to use port 80
- –preferred-challenges tls-sni to use port 443
What is the correct syntax? or do they both work? I also see some people discussing tls-sni-01 and tls-sni-02, so I suppose if tls-sni works then it’s using tls-sni-01 by default, correct?
@schoen can you take this one?
Currently Certbot does not know about any version of tls-sni other than tls-sni-01. Therefore, when you specify tls-sni, it means the same as tls-sni-01 in any Certbot version released so far.
This might not always be true in the future. Personally, I would recommend
--preferred-challenges tls-sni-01 to avoid any confusion. However, I don’t know what the default behavior will be in the future if Certbot implements other versions of tls-sni; maybe @bmw can comment on this. My guess would be that, in case of ambiguity, it would default to “the most recent version of tls-sni implemented by Certbot”.
Or perhaps “the most recent version implemented by both Certbot and the ACME server”?
Edit: I don’t know how ACME v2 will work, but if, for the sake of argument, someone added TLS-SNI-02 support to Certbot, and created a CA called Encrypt Let’s with a TLS-SNI-02 fork of Boulder, Certbot could decide which version to use based on the list of pending challenges in the authz, right?
@schoen, thanks for the answer. I think it would be better if the document could be updated with the answer to avoid confusion.
I agree—it will probably become a practical issue for users with the rollout of v2 support.
This is documented in the help for the flag:
A sorted, comma delimited list of the preferred
challenge to use during authorization with the most
preferred challenge listed first (Eg, "dns" or "tls-
sni-01,http,dns"). Not all plugins support all
details. ACME Challenges are versioned, but if you
pick "http" rather than "http-01", Certbot will select
the latest version automatically. (default: )
Unfortunately, Certbot doesn’t choose the latest version supported by both the client and server and instead just tries to use the latest version supported by the client. If that version isn’t supported by the server, Certbot will error out saying that there is no way to satisfy the CA with the given set of preferred challenges.
This is unlikely to be a problem when using Certbot in the near future with Let’s Encrypt, but it could be some day. Perhaps we should change the non-verizoned challenge type to mean any version of that type with newer versions of the challenge being preferred.
It would be great if it is non-versioned, and I actually don’t know what is mean. If the certbot can decide the version for me, I don’t even care about which version you use. All I really want to do is specify what challenge(tls-sni, dns, http) to use. IMO, most people don’t really care which version is used as long as it works.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.