🔱: [acme] sync upgrade with 3 commits [trident-sync]

Bump v5.3.0
Example for dns-01
This commit is contained in:
GitHub Actions Bot
2024-02-05 19:24:09 +00:00
parent 80cd1bfc8e
commit 960f61d158
7 changed files with 181 additions and 22 deletions

View File

@@ -0,0 +1,21 @@
# dns-01
The greatest benefit of `dns-01` is that it is the only challenge type that can be used to issue ACME wildcard certificates, however it also has a few downsides. Your DNS provider needs to offer some sort of API you can use to automate adding and removing the required `TXT` DNS records. Additionally, solving DNS challenges will be much slower than the other challenge types because of DNS propagation delays.
## How it works
When solving `dns-01` challenges, you prove ownership of a domain by serving a specific payload within a specific DNS `TXT` record from the domains authoritative nameservers. The ACME authority provides the client with a token that, along with a thumbprint of your account key, is used to generate a `base64url` encoded `SHA256` digest. This payload is then placed as a `TXT` record under DNS name `_acme-challenge.$YOUR_DOMAIN`.
Once the order is finalized, the ACME authority will lookup your domains DNS record to verify that the payload is correct. `CNAME` and `NS` records are followed, should you wish to delegate challenge response to another DNS zone or record.
## Pros and cons
* Only challenge type that can be used to issue wildcard certificates
* Your DNS provider needs to supply an API that can be used
* DNS propagation time may be slow
* Useful in instances where both port 80 and 443 are unavailable
## External links
* [https://letsencrypt.org/docs/challenge-types/#dns-01-challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge)
* [https://datatracker.ietf.org/doc/html/rfc8555#section-8.4](https://datatracker.ietf.org/doc/html/rfc8555#section-8.4)

View File

@@ -0,0 +1,92 @@
/**
* Example using dns-01 challenge to generate certificates
*
* NOTE: This example is incomplete as the DNS challenge response implementation
* will be specific to your DNS providers API.
*
* NOTE: This example does not order certificates on-demand, as solving dns-01
* will likely be too slow for it to make sense. Instead, it orders a wildcard
* certificate on init before starting the HTTPS server as a demonstration.
*/
const https = require('https');
const acme = require('./../../');
const HTTPS_SERVER_PORT = 443;
const WILDCARD_DOMAIN = 'example.com';
function log(m) {
process.stdout.write(`${(new Date()).toISOString()} ${m}\n`);
}
/**
* Main
*/
(async () => {
try {
/**
* Initialize ACME client
*/
log('Initializing ACME client');
const client = new acme.Client({
directoryUrl: acme.directory.letsencrypt.staging,
accountKey: await acme.crypto.createPrivateKey()
});
/**
* Order wildcard certificate
*/
log(`Creating CSR for ${WILDCARD_DOMAIN}`);
const [key, csr] = await acme.crypto.createCsr({
commonName: WILDCARD_DOMAIN,
altNames: [`*.${WILDCARD_DOMAIN}`]
});
log(`Ordering certificate for ${WILDCARD_DOMAIN}`);
const cert = await client.auto({
csr,
email: 'test@example.com',
termsOfServiceAgreed: true,
challengePriority: ['dns-01'],
challengeCreateFn: (authz, challenge, keyAuthorization) => {
/* TODO: Implement this */
log(`[TODO] Add TXT record key=_acme-challenge.${authz.identifier.value} value=${keyAuthorization}`);
},
challengeRemoveFn: (authz, challenge, keyAuthorization) => {
/* TODO: Implement this */
log(`[TODO] Remove TXT record key=_acme-challenge.${authz.identifier.value} value=${keyAuthorization}`);
}
});
log(`Certificate for ${WILDCARD_DOMAIN} created successfully`);
/**
* HTTPS server
*/
const requestListener = (req, res) => {
log(`HTTP 200 ${req.headers.host}${req.url}`);
res.writeHead(200);
res.end('Hello world\n');
};
const httpsServer = https.createServer({
key,
cert
}, requestListener);
httpsServer.listen(HTTPS_SERVER_PORT, () => {
log(`HTTPS server listening on port ${HTTPS_SERVER_PORT}`);
});
}
catch (e) {
log(`[FATAL] ${e.message}`);
process.exit(1);
}
})();