Stateless challenge-response #61

New Issue

adam · 2025-12-29T00:23:55+01:00

adam commented

2025-12-29 00:23:55 +01:00

Originally created by @leonklingele on GitHub (Feb 16, 2016).

I found this other letsencrypt.sh project the other day: https://github.com/gheift/letsencrypt.sh
It handles the challenge-response mechanism quite nicely:

location ~ "^/\.well-known/acme-challenge/([-_a-zA-Z0-9]*)$" {
    default_type text/plain;
    return 200 "$1.ACCOUNT_THUMBPRINT";
}

Replace ACCOUNT_THUMBPRINT with the (public) thumbprint of the private key, and everything else happens automagically, without having to create any files (like this project does in /var/www/letsencrypt)

Are there any downsides to doing it this way?

Originally created by @leonklingele on GitHub (Feb 16, 2016). I found this other letsencrypt.sh project the other day: https://github.com/gheift/letsencrypt.sh It handles the challenge-response mechanism quite nicely: ``` nginx location ~ "^/\.well-known/acme-challenge/([-_a-zA-Z0-9]*)$" { default_type text/plain; return 200 "$1.ACCOUNT_THUMBPRINT"; } ``` Replace `ACCOUNT_THUMBPRINT` with the (public) thumbprint of the private key, and everything else happens automagically, without having to create any files (like this project does in `/var/www/letsencrypt`) Are there any downsides to doing it this way?

adam closed this issue

2025-12-29 00:23:55 +01:00

adam commented

2025-12-29 00:23:57 +01:00

@lukas2511 commented on GitHub (Feb 17, 2016):

I'm not sure, this way you'd always have your verification "files" in place, and an attacker having control of your account-key or a key with identical fingerprint (if that is possible) could sign certificates for all your domains.

@lukas2511 commented on GitHub (Feb 17, 2016): I'm not sure, this way you'd always have your verification "files" in place, and an attacker having control of your account-key or a key with identical fingerprint (if that is possible) could sign certificates for all your domains.

adam commented

2025-12-29 00:23:57 +01:00

@leonklingele commented on GitHub (Feb 17, 2016):

Well, if an attacker gets hold of your private key you have much worse problems to consider.
"Identical thumbprint" essentially means "same key pair", as the thumbprint is a SHA256 hash derived from the public key parts. A thumbprint hash collision with another key is so unlikely that the hash algorithm would be considered insecure. So not a problem at all.

@leonklingele commented on GitHub (Feb 17, 2016): Well, if an attacker gets hold of your private key you have much worse problems to consider. "Identical thumbprint" essentially means "same key pair", as the thumbprint is a SHA256 hash derived from the public key parts. A thumbprint hash collision with another key is so unlikely that the hash algorithm would be considered insecure. So not a problem at all.

adam commented

2025-12-29 00:23:57 +01:00

@lukas2511 commented on GitHub (Feb 17, 2016):

There were already issues involving left-over signatures: https://github.com/letsencrypt/boulder/issues/604
Probably just a conceptional issue and nothing that was really exploited, but I really dislike that it would have worked in theory.

Also leaking private keys by accident is nothing new, people accidentally hosted private keys on their websites, on GitHub, or got them stolen through software exploits.
From some of the issues I've read on this repository I actually think some people are using this script inside of /var/www/letsencrypt, basically having their private key a web-server configuration issue apart from being public...

I agree that it would look cleaner, and be a lot easier since there is nothing that has to be moved around, but I really don't want to take this risk.
If you want to do this nothing stops you from doing this, you'd just have to extract your fingerprint once, but I dislike this as a "feature" (or configuration suggestion) for this script.

@lukas2511 commented on GitHub (Feb 17, 2016): There were already issues involving left-over signatures: https://github.com/letsencrypt/boulder/issues/604 Probably just a conceptional issue and nothing that was really exploited, but I really dislike that it would have worked in theory. Also leaking private keys by accident is nothing new, people accidentally hosted private keys on their websites, on GitHub, or got them stolen through software exploits. From some of the issues I've read on this repository I actually think some people are using this script inside of `/var/www/letsencrypt`, basically having their private key a web-server configuration issue apart from being public... I agree that it would look cleaner, and be a lot easier since there is nothing that has to be moved around, but I really don't want to take this risk. If you want to do this nothing stops you from doing this, you'd just have to extract your fingerprint once, but I dislike this as a "feature" (or configuration suggestion) for this script.

adam referenced this issue

2025-12-29 01:28:29 +01:00

[PR #61] [CLOSED] Added nginx.conf.example #691

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#61