Support for tls-alpn verification #361

New Issue

adam · 2025-12-29T01:23:41+01:00

adam commented

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

Originally created by @lukas2511 on GitHub (Jul 17, 2018).

Originally assigned to: @lukas2511 on GitHub.

Dehydrated could generate tls-alpn verification certificates as another way of verification, those should be easily deployable using a new hook.

Short explanation on tls-alpn verification after reading the specs:

ALPN is a protocol extension for TLS which allows multiple protocols to be hosted on the same port (e.g. HTTP/2 and HTTP/1.1 on port 443)

tls-alpn verification uses this with a new protocol "acme-tls/1" and a specially crafted self-signed certificate containing the verification code and the dns name of the to-be-validated domain.

ca connects with the custom protocol, retrieves the certificate and does several checks on it, if everything matches the domain is validated

because of the used dns name it's no longer possible to generate certificates for other domains on a shared host, which was the reason for tls-sni being disabled

since alpn is required by http2 basically every modern webserver will support this

Technical specs for the required certificate extension:

The client prepares for validation by constructing a self-signed
certificate which MUST contain a acmeValidation-v1 extension and a
subjectAlternativeName extension [RFC5280]. The
subjectAlternativeName extension MUST contain a single dNSName entry
where the value is the domain name being validated. The
acmeValidation-v1 extension MUST contain the SHA-256 digest
[FIPS180-4] of the key authorization [I-D.ietf-acme-acme] for the
challenge. The acmeValidation extension MUST be critical so that the
certificate isn't inadvertently used by non-ACME software.

id-pe-acmeIdentifier OBJECT IDENTIFIER ::=  { id-pe 30 }
id-pe-acmeIdentifier-v1 OBJECT IDENTIFIER ::=  { id-pe-acmeIdentifier 1 }
acmeValidation-v1 ::= OCTET STRING (SIZE (32))

Originally created by @lukas2511 on GitHub (Jul 17, 2018). Originally assigned to: @lukas2511 on GitHub. Dehydrated could generate tls-alpn verification certificates as another way of verification, those should be easily deployable using a new hook. Short explanation on tls-alpn verification after reading the specs: > ALPN is a protocol extension for TLS which allows multiple protocols to be hosted on the same port (e.g. HTTP/2 and HTTP/1.1 on port 443) > > tls-alpn verification uses this with a new protocol "acme-tls/1" and a specially crafted self-signed certificate containing the verification code and the dns name of the to-be-validated domain. > > ca connects with the custom protocol, retrieves the certificate and does several checks on it, if everything matches the domain is validated > > because of the used dns name it's no longer possible to generate certificates for other domains on a shared host, which was the reason for tls-sni being disabled > > since alpn is required by http2 basically every modern webserver will support this Technical specs for the required certificate extension: > The client prepares for validation by constructing a self-signed > certificate which MUST contain a acmeValidation-v1 extension and a > subjectAlternativeName extension [RFC5280]. The > subjectAlternativeName extension MUST contain a single dNSName entry > where the value is the domain name being validated. The > acmeValidation-v1 extension MUST contain the SHA-256 digest > [FIPS180-4] of the key authorization [I-D.ietf-acme-acme] for the > challenge. The acmeValidation extension MUST be critical so that the > certificate isn't inadvertently used by non-ACME software. ``` id-pe-acmeIdentifier OBJECT IDENTIFIER ::= { id-pe 30 } id-pe-acmeIdentifier-v1 OBJECT IDENTIFIER ::= { id-pe-acmeIdentifier 1 } acmeValidation-v1 ::= OCTET STRING (SIZE (32)) ```

adam closed this issue

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

adam commented

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

@lukas2511 commented on GitHub (Jul 26, 2018):

So, I experimented a bit with this.

Generating the certificate seems very easy; The changes to dehydrated itself are minimal, I'm actually generating the verification certificate inside my hook-script for now.

The hard part is actually using it...

As far as I can see there is absolutely no support for working with custom ALPNs in any better-known webserver, and I think that kinda makes sense, after all they are made to reply to web-requests, not anything else.

I was able to use nginx's ssl_preread module on my load-balancer to at least forward those requests to a different port, this should be a good starting point.

I guess I'll try to find or write a simple responder...

@lukas2511 commented on GitHub (Jul 26, 2018): So, I experimented a bit with this. Generating the certificate seems very easy; The changes to dehydrated itself are minimal, I'm actually generating the verification certificate inside my hook-script for now. The hard part is actually using it... As far as I can see there is absolutely no support for working with custom ALPNs in any better-known webserver, and I think that kinda makes sense, after all they are made to reply to web-requests, not anything else. I was able to use nginx's ssl_preread module on my load-balancer to at least forward those requests to a different port, this should be a good starting point. I guess I'll try to find or write a simple responder...

adam commented

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

@lukas2511 commented on GitHub (Jul 26, 2018):

With fba49ba28e dehydrated now supports tls-alpn-01 verification. I added my example responder and load-balancer config to the docs directory, please handle with care.

@lukas2511 commented on GitHub (Jul 26, 2018): With fba49ba28eb746eae127aa36e7f515beeaf0bbae dehydrated now supports tls-alpn-01 verification. I added my example responder and load-balancer config to the docs directory, please handle with care.

adam commented

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

@waynew commented on GitHub (Mar 16, 2019):

Hey - what version of nginx were you using? I tried your example config and I kept getting garbage errors, so I'm not sure if it's just because 1.10 is too old (I can go ask on serverfault or something to get more specific help if that's not the case)

@waynew commented on GitHub (Mar 16, 2019): Hey - what version of nginx were you using? I tried your example config and I kept getting garbage errors, so I'm not sure if it's just because 1.10 is too old (I can go ask on serverfault or something to get more specific help if that's not the case)

adam commented

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

@lukas2511 commented on GitHub (Mar 16, 2019):

@waynew You'll need at least nginx 1.13.10 as you'll require the $ssl_preread_alpn_protocols variable for a TCP proxy / TLS preread.

@lukas2511 commented on GitHub (Mar 16, 2019): @waynew You'll need at least nginx 1.13.10 as you'll require the $ssl_preread_alpn_protocols variable for a TCP proxy / TLS preread.

adam referenced this issue

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

[PR #361] [CLOSED] Update contact of account #811

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#361