tls-alpn-01 Challenge¶
With the tls-alpn-01
challenge, you prove to the CA that you are able to control the web server of the domain to be authorized, by letting it respond to a request with a specific self-signed cert utilizing the ALPN extension. This challenge is specified in RFC 8737.
TlsAlpn01Challenge
provides a byte array called acmeValidation
:
TlsAlpn01Challenge challenge = auth.findChallenge(TlsAlpn01Challenge.class);
Identifier identifier = auth.getIdentifier();
byte[] acmeValidation = challenge.getAcmeValidation();
You need to create a self-signed certificate with the domain to be validated set as the only Subject Alternative Name. The acmeValidation
must be set as DER encoded OCTET STRING
extension with the object id 1.3.6.1.5.5.7.1.31
. It is required to set this extension as critical.
After that, configure your web server so it will use this certificate on an incoming TLS request having the SNI identifier
and the ALPN protocol acme-tls/1
.
The TlsAlpn01Challenge
class does not generate a self-signed certificate for you, as it would require Bouncy Castle. However, there is a utility method in the acme4j-utils module for this use case:
KeyPair certKeyPair = KeyPairUtils.createKeyPair(2048);
X509Certificate cert = CertificateUtils.
createTlsAlpn01Certificate(certKeyPair, identifier, acmeValidation);
Now use cert
and certKeyPair
to let your web server respond to TLS requests containing an ALPN extension with the value acme-tls/1
and a SNI extension containing your subject (identifier
).
Note
The request is sent to port 443 only. If your domain has multiple IP addresses, the CA randomly selects some of them. There is no way to choose a different port or a fixed IP address.
Your server should be able to handle multiple requests to the challenge. The ACME server may check your response multiple times, and from different IPs. Also keep your response available until the Authorization
status has changed to VALID
or INVALID
.