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.
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))
```
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...
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.
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)
@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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
Technical specs for the required certificate extension:
@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):
With
fba49ba28edehydrated now supports tls-alpn-01 verification. I added my example responder and load-balancer config to the docs directory, please handle with care.@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)
@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.