Lets Encrypt / Certbot – Request strong certificate
sudo certbot certonly \
--key-type rsa \
--rsa-key-size 4096 \
--key-type ecdsa \
--elliptic-curve secp384r1 \
--dns-cloudflare \
--dns-cloudflare-credentials /root/cloudfare \
--dns-cloudflare-propagation-seconds 30 \
-d test.scito.dk \
-v
The credential file should have the CHMOD of 600
sudo chmod 600 /root/cloudfare
Explanation of Each Option
Option | Description |
---|---|
sudo | Runs the command with root privileges. Required for Certbot to modify system files and configurations. |
certbot | The client software for Let’s Encrypt that automates certificate issuance. |
certonly | Tells Certbot to only obtain a certificate, without trying to install it automatically. Useful for custom web server setups. |
Key Options (Certificate Parameters)
Option | Purpose |
---|---|
–key-type rsa | Requests a certificate using an RSA private key. |
–rsa-key-size 4096 | Sets the size of the RSA key to 4096 bits for higher cryptographic strength. |
–key-type ecdsa | Requests a certificate using an ECDSA private key as well. Certbot will generate both types if this and rsa are specified. |
–elliptic-curve secp384r1 | Specifies the elliptic curve to use for the ECDSA key. secp384r1 is a high-security curve commonly supported. |
Note: When both rsa and ecdsa key types are defined, Certbot will generate and store both certificates (in different directories), but it’s up to the user/server config to use the desired one.
DNS Validation with Cloudflare
Option | Explanation |
---|---|
–dns-cloudflare | Enables the DNS-01 challenge method using the Cloudflare plugin. This is necessary for issuing wildcard certificates or when HTTP-01 validation isn’t possible. |
–dns-cloudflare-credentials /root/cloudfare | Path to the credentials file containing your Cloudflare API token or global key. Required for authenticating with the Cloudflare API. |
–dns-cloudflare-propagation-seconds 30 | Specifies how long Certbot should wait (in seconds) for DNS changes to propagate. Some DNS providers require a longer delay; 30s is a low but aggressive value. |
Domain and Verbosity
Option | Function |
---|---|
-d test.scito.dk | The domain name for which the certificate is being requested. You can add multiple -d flags for SAN/multi-domain certificates. |
-v | Enables verbose mode, providing detailed output for debugging or logging purposes. |
Summary
This command is designed to:
- Obtain certificates for both RSA (4096-bit) and ECDSA (secp384r1) keys,
- Validate ownership of test.scito.dk using Cloudflare DNS API,
- Wait 30 seconds for DNS record propagation,
- Save the certificates locally without auto-installation,
- Output verbose debug information.
It’s suitable for advanced users who manage their own web servers and prefer fine-tuned control over certificate type and issuance mechanics.
Why These Certbot Options Improve Security
he default certbot behavior prioritizes convenience and compatibility, often using standard RSA-2048 keys and HTTP-01 validation. While still secure, your custom options increase cryptographic strength, reduce attack surface, and better support modern TLS standards.
1.
–rsa-key-size 4096
(vs default 2048)
Stronger RSA keys:
- Default Certbot uses RSA with a 2048-bit key.
- Your command explicitly uses a 4096-bit RSA key, doubling the key length.
Why it’s more secure:
- RSA-4096 is significantly more resistant to brute-force attacks.
- While RSA-2048 is still considered secure, 4096 offers a larger safety margin, especially for long-lived certificates or highly sensitive applications.
2.
–key-type ecdsa –elliptic-curve secp384r1
Elliptic Curve Cryptography (ECC):
- ECDSA with secp384r1 provides stronger security per bit and faster performance than RSA.
- The secp384r1 curve is more secure than the commonly used secp256r1 and offers future-proofing.
Why it’s more secure:
- ECC keys are smaller but harder to break than equivalent RSA keys.
- secp384r1 is recognized as secure even against projected future advances in computing.
- You enable dual support: clients that prefer ECDSA get stronger, more efficient crypto.
3.
–dns-cloudflare
(vs default HTTP-01)
DNS-01 Challenge:
- Certbot defaults to the HTTP-01 challenge, which requires exposing a web server and a specific HTTP path.
- You’re using DNS-01 via Cloudflare, which avoids exposing any public service during validation.
Why it’s more secure:
- Avoids relying on inbound HTTP traffic—no open ports required.
- Prevents potential abuse of misconfigured HTTP routes or proxies during validation.
- DNS-01 can also be used to validate wildcard domains, something HTTP-01 cannot do.
4.
–dns-cloudflare-credentials /root/cloudfare
Credential security:
- You’re using an API token stored in a local file.
- Certbot reads the token at runtime; it’s never exposed in logs or arguments.
Why it’s more secure:
- DNS API keys can be scoped with least privilege, e.g., only allowing TXT record edits.
- When secured properly (as in /root/), it limits exposure to only privileged users.
5.
–dns-cloudflare-propagation-seconds 30
Reduced failure exposure:
- Some DNS providers may delay propagation. If Certbot checks too soon, validation can fail.
- By explicitly waiting 30 seconds, you reduce the chance of failed validations that could cause retries or partial provisioning.
Why it matters:
Reliable validation reduces attack windows during renewal automation or domain switching.
Option | Security Benefit |
---|---|
rsa-key-size 4096 | Stronger RSA key = higher brute-force resistance |
ecdsa secp384r1 | Smaller, faster, and more secure than RSA |
dns-cloudflare | Avoids exposing HTTP server; supports wildcard |
credentials file | Keeps API tokens local and secure |
propagation wait | Improves reliability, reduces misconfiguration |