39 lines
1.2 KiB
Markdown
39 lines
1.2 KiB
Markdown
# TLS for DWH REST
|
|
|
|
The DWH key may be used only over verified TLS. Authorization or availability errors never justify
|
|
disabling certificate verification.
|
|
|
|
## Private CA
|
|
|
|
When DWH REST uses an enterprise CA, deliver the certificate separately from the API key. The CA
|
|
is not a credential, but its integrity is part of the security boundary. Keep it out of Git and
|
|
make it unwritable by unauthorized users.
|
|
|
|
Esempio ACME Limited:
|
|
|
|
```dotenv
|
|
THT_WS_ACME_EBIKES_DWH_TLS_CA_FILE=/run/secrets/acme-ebikes-dwh-ca.pem
|
|
```
|
|
|
|
## Out-of-band fingerprint
|
|
|
|
Calculate the fingerprint of the received file and compare it through an independent channel:
|
|
|
|
```bash
|
|
openssl x509 -noout -fingerprint -sha256 \
|
|
-in /absolute/protected/acme-ebikes-dwh-ca.pem
|
|
```
|
|
|
|
The certificate SAN must include the exact name used by the binding, such as `dwh.acme.example`.
|
|
|
|
## Renewal
|
|
|
|
1. Prepare the new certificate and chain.
|
|
2. Confirm the SAN and fingerprint out of band.
|
|
3. Distribute the new CA to clients while temporarily keeping the old one.
|
|
4. Update the binding and confirm connectivity with normal TLS.
|
|
5. Install the server certificate.
|
|
6. Remove the old trust after the agreed window.
|
|
|
|
Do not use `curl -k`, disable TLS, or embed complete certificates or fingerprints in shared documents.
|