Operations grimoire/TLS certificates: Difference between revisions
(Switch to acme-v02.api.letsencrypt.org) |
(Rollover procedure of a certificate should know about https://devcentral.nasqueron.org/D3271) |
||
| (13 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
TLS certificates should be used for every service we provide, so we can encrypt the communications. | |||
== Let's encrypt commands == | == Let's Encrypt == | ||
=== Let's encrypt commands === | |||
'''2016-07-31 | '''2016-07-31 utility rename.''' Client upgraded on Ysul. New client name is certbot, not anymore letsencrypt.''' | ||
'''acme-v02 migration.''' If you've a complaint acme-v01.api. isn't available, add <code>--server https://acme-v02.api.letsencrypt.org/directory</code>. | |||
<code>certbot certonly | ==== Generate a certificate ==== | ||
Devserver role, for example Ysul or WindRiver (/var/letsencrypt-auto folder) : | |||
<code>certbot certonly -a webroot --webroot-path=/var/letsencrypt-auto -d foo.nasqueron.org</code> | |||
Dwellers (container will use /www): | Dwellers (container will use /www): | ||
<code> | <code>certbot certonly --server https://acme-v02.api.letsencrypt.org/directory -a webroot --webroot-path=/www -d bar.nasqueron.org</code> | ||
=== Generate a certificate for several sites === | ==== Generate a certificate for several sites ==== | ||
<code>-d foo.nasqueron.org -d bar.nasqueron.org</code> | <code>-d foo.nasqueron.org -d bar.nasqueron.org</code> | ||
If a certificate for foo already existed, it will offer to extend it to a new alternative name, which is probably a good idea. | If a certificate for foo already existed, it will offer to extend it to a new alternative name, which is probably a good idea. | ||
=== Renew all certificates === | ==== Generate a certificate through DNS ==== | ||
DNS can be used to generate certificates for domains. For example, the Openfire XMPP certificate is generated like this: | |||
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth --preferred-challenges dns --debug-challenges -d xmpp.nasqueron.org -d nasqueron.org -d conference.nasqueron.org | |||
From December 2023, you can use this command on FreeBSD servers where {{T|1505}} Let's Encrypt standard installation have been deployed: | |||
certbot certonly --manual --manual-auth-hook /usr/local/etc/letsencrypt/acme-dns-auth --preferred-challenges dns --debug-challenges -d subdomain.nasqueron.org | |||
This uses a specialized DNS server deployed on our Docker PaaS to serve dynamic TLS records under .acme.nasqueron.org, {{Ops file|roles/paas-docker/containers/acme_dns.sls}}. | |||
Support files were previously '''only deployed to paas-docker role''' through {{Ops file|roles/paas-docker/letsencrypt/files}}. | |||
==== Renew all certificates ==== | |||
<code>certbot renew</code> | |||
==== Installation on nginx ==== | |||
===== Allow Let's encrypt validation ===== | |||
include includes/letsencrypt; | |||
This will use {{Ops file|roles/webserver-core/nginx/files/includes/letsencrypt}} nginx configuration. | |||
===== Serve TLS certificate ===== | |||
include includes/tls; | |||
ssl_certificate /srv/letsencrypt/etc/live/xmpp.nasqueron.org/fullchain.pem; | |||
ssl_certificate_key /srv/letsencrypt/etc/live/xmpp.nasqueron.org/privkey.pem; | |||
This will configure a compromise between security and compatibility, based on Intermediate Mozilla SSL config<ref>https://ssl-config.mozilla.org/</ref>. The current configuration is served by {{Ops file|roles/webserver-core/nginx/files/includes/tls}}. | |||
If you prefer to restrict the resource for TLS 1.3, and accepts to block legacy clients, you can also use with {{D|3251}}: | |||
include includes/tls-modern-only; | |||
ssl_certificate /srv/letsencrypt/etc/live/xmpp.nasqueron.org/fullchain.pem; | |||
ssl_certificate_key /srv/letsencrypt/etc/live/xmpp.nasqueron.org/privkey.pem; | |||
== Nasqueron PKI == | |||
=== Principles === | |||
Internal PKI material are stored in Vault, see [[Operations grimoire/Vault]] for information about how to generate, renew, etc. | |||
In the operations repository, the {{Ops file|roles/core/certificates}} unit is responsible to deploy <code>nasqueron-vault-ca.crt</code>, used to authenticate for *.nasqueron.drake or IP services. For exemple, Vault clients require a certificate they can validate with a chain from that intermediate CA. Note as we don't currently use the root CA, a fullchain is probably not needed for those services. | |||
=== | === Rollover a new certificate === | ||
= | If <code>nasqueron-vault-ca.crt</code> is updated or if we want instead to provision the root certificate, the following repository need to be updated and services to be redeployed: | ||
{| class="wikitable sortable" | |||
|+ Where to update certificate? | |||
|- | |||
! Repository !! Path !! Purpose !! Deployment instructions | |||
|- | |||
| operations || {{Ops file|roles/core/certificates/files/}} || Trust internal resources on every server || Salt: <code>salt '*' state.apply roles/core/certificates</code> | |||
|- | |||
| docker-airflow || [https://devcentral.nasqueron.org/source/docker-airflow/browse/main/files files/] || Connect to Vault from Airflow Python code || Docker: build and deploy new image nasqueron/airflow on Dwellers | |||
|} | |||
Deployment instructions are up-to-date when newly added on that table. Afterwards, they should be checked against current procedures. | |||
== Special considerations == | == Special considerations == | ||
| Line 34: | Line 86: | ||
Fill a task in Servers component, subscribe Sandlayth and Dereckson to deploy it on a new server. | Fill a task in Servers component, subscribe Sandlayth and Dereckson to deploy it on a new server. | ||
A salt state would be nice for such purpose. | A salt state would be nice for such purpose. There is work-in-progress on that matter through {{D|3248}}. | ||
=== Internationalized domain names === | === Internationalized domain names === | ||
| Line 41: | Line 93: | ||
https://www.punycoder.com/ | https://www.punycoder.com/ | ||
==== | ==== Let's encrypt support ==== | ||
Let's encrypt | Let's encrypt has supported IDN since 2016<ref>https://letsencrypt.org/2016/10/21/introducing-idn-support.html</ref>. We use it for dægrefn.nasqueron.org certificate. | ||
Previously, they were afraid: attackers could register a domain with a Cyrillic character matching a real domains. As some people consider it's the responsibility of the CA to mitigate such risks, the feature has been several times postponed. | |||
==== StartSSL ==== | ==== StartSSL ==== | ||
StartSSL is not in activity anymore. It was used at Nasqueron when Let's Encrypt didn't support IDN. | |||
== Notes & references == | |||
<references /> | |||
Latest revision as of 23:03, 12 January 2024
TLS certificates should be used for every service we provide, so we can encrypt the communications.
Let's Encrypt
Let's encrypt commands
2016-07-31 utility rename. Client upgraded on Ysul. New client name is certbot, not anymore letsencrypt.
acme-v02 migration. If you've a complaint acme-v01.api. isn't available, add --server https://acme-v02.api.letsencrypt.org/directory.
Generate a certificate
Devserver role, for example Ysul or WindRiver (/var/letsencrypt-auto folder) :
certbot certonly -a webroot --webroot-path=/var/letsencrypt-auto -d foo.nasqueron.org
Dwellers (container will use /www):
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory -a webroot --webroot-path=/www -d bar.nasqueron.org
Generate a certificate for several sites
-d foo.nasqueron.org -d bar.nasqueron.org
If a certificate for foo already existed, it will offer to extend it to a new alternative name, which is probably a good idea.
Generate a certificate through DNS
DNS can be used to generate certificates for domains. For example, the Openfire XMPP certificate is generated like this:
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth --preferred-challenges dns --debug-challenges -d xmpp.nasqueron.org -d nasqueron.org -d conference.nasqueron.org
From December 2023, you can use this command on FreeBSD servers where T1505 Let's Encrypt standard installation have been deployed:
certbot certonly --manual --manual-auth-hook /usr/local/etc/letsencrypt/acme-dns-auth --preferred-challenges dns --debug-challenges -d subdomain.nasqueron.org
This uses a specialized DNS server deployed on our Docker PaaS to serve dynamic TLS records under .acme.nasqueron.org, rOPS: roles/paas-docker/containers/acme_dns.sls.
Support files were previously only deployed to paas-docker role through rOPS: roles/paas-docker/letsencrypt/files.
Renew all certificates
certbot renew
Installation on nginx
Allow Let's encrypt validation
include includes/letsencrypt;
This will use rOPS: roles/webserver-core/nginx/files/includes/letsencrypt nginx configuration.
Serve TLS certificate
include includes/tls; ssl_certificate /srv/letsencrypt/etc/live/xmpp.nasqueron.org/fullchain.pem; ssl_certificate_key /srv/letsencrypt/etc/live/xmpp.nasqueron.org/privkey.pem;
This will configure a compromise between security and compatibility, based on Intermediate Mozilla SSL config[1]. The current configuration is served by rOPS: roles/webserver-core/nginx/files/includes/tls.
If you prefer to restrict the resource for TLS 1.3, and accepts to block legacy clients, you can also use with D3251:
include includes/tls-modern-only; ssl_certificate /srv/letsencrypt/etc/live/xmpp.nasqueron.org/fullchain.pem; ssl_certificate_key /srv/letsencrypt/etc/live/xmpp.nasqueron.org/privkey.pem;
Nasqueron PKI
Principles
Internal PKI material are stored in Vault, see Operations grimoire/Vault for information about how to generate, renew, etc.
In the operations repository, the rOPS: roles/core/certificates unit is responsible to deploy nasqueron-vault-ca.crt, used to authenticate for *.nasqueron.drake or IP services. For exemple, Vault clients require a certificate they can validate with a chain from that intermediate CA. Note as we don't currently use the root CA, a fullchain is probably not needed for those services.
Rollover a new certificate
If nasqueron-vault-ca.crt is updated or if we want instead to provision the root certificate, the following repository need to be updated and services to be redeployed:
| Repository | Path | Purpose | Deployment instructions |
|---|---|---|---|
| operations | rOPS: roles/core/certificates/files/ | Trust internal resources on every server | Salt: salt '*' state.apply roles/core/certificates
|
| docker-airflow | files/ | Connect to Vault from Airflow Python code | Docker: build and deploy new image nasqueron/airflow on Dwellers |
Deployment instructions are up-to-date when newly added on that table. Afterwards, they should be checked against current procedures.
Special considerations
New server
Let's encrypt client is available on Ysul (natively) and Dwellers (as a wrapper script for a Docker container).
Fill a task in Servers component, subscribe Sandlayth and Dereckson to deploy it on a new server.
A salt state would be nice for such purpose. There is work-in-progress on that matter through D3248.
Internationalized domain names
Punycode conversion
Both for web server configuration and certificate authority, name must be converted to Punycode (RFC 3492): https://www.punycoder.com/
Let's encrypt support
Let's encrypt has supported IDN since 2016[2]. We use it for dægrefn.nasqueron.org certificate.
Previously, they were afraid: attackers could register a domain with a Cyrillic character matching a real domains. As some people consider it's the responsibility of the CA to mitigate such risks, the feature has been several times postponed.
StartSSL
StartSSL is not in activity anymore. It was used at Nasqueron when Let's Encrypt didn't support IDN.
