291 private links
The websites must renew their certificates. Certificates are issued for two years but it's hard to renew certificates after two years! Let's Encrypt came up with a brilliant idea: all certificates are valid for only 90 days.
It has two advantates: it rotates the private key every 90 days and it pushes website owner to automate the renewal process.
In case of private key compromission, there are two methods to revoke the certificates: CRL and OCSP.
In principle, CA certificates themselves carry this information, informing clients that when verifying a certificate, they should visit this URL list to check if the certificate they are validating is in the revocation list. If it is, they should not trust it.
The CRL provides exactly that with the DER format.
The OCSP method needs to verify every URL of each certificates. This method has downsides:
- The website's performance will decrease due to the additional time required for CA requests. The OCSP servers could become htspots and might be overloaded by clients.
- The CA will know which domain names the client has accessed.
- If the CA's OCSP service is down, the client has two choices: ignore verification or no trust the target site.
There can be workarounds with the OCSP Stapling: the website itself query the CA's OCSP service and when a client visits the website, the website provides the OCSP response.
All of these methods works if the CA can be trusted. WoSign had for example a chaotic organization that issued certificates for websites directly, whereas the CA should have issued certificates for Chinese users only.
That's what Certificate Transparency (CT) should address after the DigiNotar incident in 2011.n CT must log the issued certificate in a CT database and the CT will provide a Signed Certificate Timestamp (SCT) back to the website. The clients will only trust certificates that have an SCT when visiting websites and websites (and everyone) can monitor the CT database to check if any certificates have been issued for their domains.
The client must have CA Root. Once the CA Root is verified, the client cana trust the certificates signed by the root and its other intermediate certificates.
Verification starts from the certificate of the domain. If it’s valid, the client verifies its issuer, and continues this process until reaching a certificate where the issuer is itself, indicating it is a Root.
For lyokolux.space, it goes as follow:
$openssl s_client -showcerts -connect lyokolux.space:443 -servername lyokolux.space 2> /dev/null | grep -A1 s:
0 s:CN = lyokolux.space
i:C = US, O = Let's Encrypt, CN = E8
--
1 s:C = US, O = Let's Encrypt, CN = E8
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1lyokolux.space is certified by Let's Encrypt. Let's Ecrypt is certified by the root certificate ISRG Root X1. The browser also tells ISRG Root X1 is a Certificate Authority.
Following the incident of DST Root CA X3 with a notable certificate expiration, the browsers started to trust Let's Encrypt directly. It seems openssl does it too because we don't see the certificate of ISRG Root X1 in the openssl output. The let's encrypt certificate is trusted because of ISRF Root XA.
- A certificate can have only one issuer because the issuer is a fixed field in the certificate, not a list.
- The essence of signing is just appending a hash value encrypted with a private key.
- Intermediate certificates are not directly trusted by clients; clients only trust Root CAs.
To increase security, a certificate can be cross-signed and verified by one or the other sources. It's up to the client or the software to trust root certificates. When the client further narrows down the trusted list to only its certificates (or its CA), this is Client Certificate Pinning. For example, the TikTok app uses this.
Next: https://shaarli.lyokolux.space/shaare/13012
Previous: https://shaarli.lyokolux.space/shaare/1ar20g
Their relationship is:
- The client trusts the CA (for example Let's Encrypt)
- The CA issues certificates to websites (often certified by the industry standard ACME Challenge) .
- When a client visits a website, the website presents its certificate. Since the client trusts the CA, it also trusts the certificate issued by the CA.
To adress a privacy key leak by the CA, they often use intermediate certificates. That's the standard x509. The CA:FALSE value on certificates issued to entities means that even if they issue a certificate, it won't be trusted. So only root and intermediate certificates can be trusted to issue other certificates.
To trust a CA, the client store the CA locally.
Two posts follows:
Si le serveur n'est pas accessible publiquement, il est tout de même possible de tester la sécurité de la configuration HTTPS
A l'établissement d'une première connexion RusTLS est 10% plus rapide qu'OpenSSL, de 20 à 40% plus rapide lors d'une nouvelles connexion client... et il fait encore mieux sur des sessions pour lesquelles il y a déjà eu une négociation TLS préalable : de 10 à 20% pour la reprise d'une session serveur et de 30 à 70% pour la reprise d'une session client. Côté transfert de données, même constat car toujours selon Joseph Birr-Pixton, l'envoi de données est 15% plus rapide et la réception 5% plus rapide. Cerise sur le gateau, RustTLS se montre moitié moins gourmand en mémoire.
<3
Un générator de configuration pour SSL. Mais ... c'est... génial !