Pour générer une clé privée non chiffrée (private.key) et sa demande de certificat associé (demande.csr) à transmettre à une autorité de certification :
Un certificat avec **subjectAltName** permet d'ajouter des noms de domaine secondaires (*subjectAltName*) en plus du nom de domaine principal (*Common Name*), ce qui est supporté par 99.9% des navigateurs récents (mais cela coûte cher chez les autorités de certification).
### Vérifier la correspondance entre clé privée / certificat / .csr
Pour s'assurer qu'un certificat est bien issu d'un clé privée, ou d'une demande de certificat (.csr), on peut vérifier la correspondance grâce au *modulus* que l'on peut extraire et comparer :
Puis, interroger le serveur OCSP obtenu (ici http://ocsp.example.com) avec la chaîne de certification (chainfile.pem) et le certificat (certificat.crt) à vérifier :
Dans le cas où un proxy filtrant est utilisé, il faut bien penser à autoriser les domaines/IP des serveurs OCSP en question, sinon on récupère une erreur 403 et la requête OCSP n'est pas validée.
Dans le cas d'un **certificat révoqué** on verra les lignes suivantes :
Pour un service en HTTPS avec l'option SNI qui permet d'envoyer un nom de domaine au sein du protocole SSL/TLS (supporté par 99.9% des navigateurs récents) :
Si le code de retour est différent de 0, le certificat n'est pas conforme pour différentes raisons :
* *Verify return code: 21 (unable to verify the first certificate)* : le certificat distant est signé par un certificat CA qui n'est pas dans votre base locale *ou* utilise un certificat intermédiaire inconnu (Note: il peut y avoir toute une chaîne de certification avec plusieurs certificats intermédiaires)
Un script Bash permet également d'effectuer des vérifications : <https://github.com/drwetter/testssl.sh>
### Vérifier la conformité d'un certificat via des services externes
Nous conseillons d'utiliser l'outil complet SSL LABS : <https://www.ssllabs.com/ssltest/analyze.html>
D'autres outils également utiles :
* Pour une vérification simple (conforme ou non): <https://ssltools.thawte.com/checker/views/certCheck.jsp>
* Pour une vérification de la châine de certification : <https://whatsmychaincert.com/>
* Pour une vérification avancée : <https://ssldecoder.org/>
* Pour une vérification SSL/TLS orientée SMTP : <https://tls.imirhil.fr>
## Louer un certificat auprès d'une autorité de certificat
État du marche en 2015 : <http://www.netcraft.com/internet-data-mining/ssl-survey/>
* StarCom/StartSSL a été [racheté en 2016 par l'autorité de certification chinoise WoSign](https://www.wosign.com/english/News/WoSign_completed_equity_investment_to_StartCom_CA.htm) qui [a de nombreux problèmes selon la fondation Mozilla](https://wiki.mozilla.org/CA:WoSign_Issues)... ce qui a pour conséquence que [Mozilla envisage de retirer les certificats CA de StartSSL](https://groups.google.com/forum/?nomobile=true#!topic/mozilla.dev.security.policy/BV5XyFJLnQM), notamment [Firefox 51 devrait bannir les certificats émis par StartCom/StartSSL à partir du 21 octobre 2016 !!](https://bugzilla.mozilla.org/show_bug.cgi?id=1311832)
* les certificats gratuits mentionnent les informations personnelles de la personne physique qui a créé le compte
* la gestion du renouvellement est lourde (votre compte expire tous les ans, et vous ne pouvez le renouveler que quelques jours avant...)
* vous pouvez créer uniquement des certificats liés à la personne physique qui a créé le compte (nom de domaine qui vous appartient personnellement ou appartient à votre société) : si vous créez plusieurs certificats pour le compte d'autres sociétés (vos clients par exemple) StartSSL finira pas rejeter vos demandes et vous devrez créer un compte pour chaque société
* la révocation d'un certificat est payante (environ 20 EUR)
L'avantage de StartSSL est que pour 150 EUR/an, vous pouvez obtenir la validation « Organization » (après une lourde procédure de vérifications) et créer ensuite une infinité de certificats Wildcard valables 3 ans.
Nous détaillons ci-dessous quelques failles célèbres, une liste de toutes les failles étant [disponible sur le wiki de Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS#Attacks_on_SSL_and_TLS).
La faille POODLE (adding Oracle On Downgraded Legacy Encryption) est une vulnérabilité touchant le protocole SSL version 3.0 permettant une attaque *man-in-the-middle*. Elle a été révélée en octobre 2014 et il y a eu une vague de désactivation du protocole SSLv3, voir <http://disablessl3.com/>.
* Désactiver SSL 3.0 pour Apache : `SSLProtocol all -SSLv2 -SSLv3`
* Désactiver SSL 3.0 pour Nginx 0.7 : `ssl_protocols TLSv1;`
La faille FREAK (Factoring RSA Export Keys) est une vulnérabilité dans OpenSSL permettant une attaque *man-in-the-middle* pour renégocier
un chiffrement faible. Cela se base sur des chiffrements « EXPORT » introduits dans les années 2000 par les USA pour pouvoir déchiffrement les communications. Voir <http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html>, <https://freakattack.com/#sysadmin> et <https://www.smacktls.com/>.
On peut tester si un serveur accepte les chiffrements EXPORT avec la commande suivante :
Si on obtient *error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:749* c'est que le serveur n'accepte pas les chiffrements EXPORT.
Debian [a corrigé cette faille en janvier2015](https://security-tracker.debian.org/tracker/CVE-2015-0204), ce qui est surtout important pour les clients (navigateurs, etc.). On peut vérifier que sa machine ne tolère pas de chiffrements « EXPORT » via la commande `openssl ciphers | tr -s ':' '\n' | sort | grep EXP`. Sous Debian, par défaut Apache et Nginx n'ont pas été impactés car leur liste de chiffrement n'incluait pas EXPORT.
- la taille de la clé privée est d'au moins 2048 bits (4096 bits est recommandé mais cela impacte les performances) ;
- le certificat et le(s) certificat(s) intermédiaire(s) utilisent des fonctions de hashage en SHA-2 (et non plus en SHA-1 qui est déprécié) ;
- le serveur HTTPS n'autorise pas l'utilisation d'algorithmes de chiffrement « faibles » avec le client (comme RC4, MD5, etc.) ;
- pour implémenter le principe de *Forward Secrecy*, le serveur HTTPS utilise des [paramètres DH (Diffie-Hellman) d'au moins 2048 bits](https://weakdh.org/) (ou 4096 bits si c'est la taille de la clé privée) ;
- le serveur HTTPS autorise le protocole TLS 1.2 ;
- le serveur HTTPS permet la [réutilisation des sessions SSL](https://vincent.bernat.im/fr/blog/2011-sessions-ssl-rfc5077.html) ;
- un [entête *Strict-Transport-Security*](http://www.bortzmeyer.org/6797.html) indique que le site n'est consultable qu'en HTTPS pendant au moins 180 jours.
Plus généralement, on utilisera la documentation de référence <https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations> et notamment le [générateur de configuration SSL de Mozilla](https://mozilla.github.io/server-side-tls/ssl-config-generator/).
Suite à la mise en place d'un nouveau certificat délivré par StartSSL, vous obtenez une erreur du type "An error occurred during a connection to ssl.example.com. The OCSP server has no status for the certificate. (Error code: sec_error_ocsp_unknown_cert) ?
StartSSL semble mettre entre 6 et 12h à propager ses nouveaux certificats sur son serveur OCSP. Il faut donc patienter…
### Bug avec Firefox et l'interface d'administration de StartSSL
Il y a un bug avec l'interface d'administration StartSSL avec Firefox (Firefox embarque un mauvais certificat). Voir le bug report <https://bugzilla.mozilla.org/show_bug.cgi?id=1037080> et une solution temporaire : <https://forum.startcom.org/viewtopic.php?p=8204#p8204>
Il faut supprimer le certificat "StartCom? Certification Authority" de l'autorité StartCom de type "Securité personne" (Software Security Device) dans les préférences de Firefox (Avancée --> Certificat). Voir <https://lut.im/EPSYOXoy/ckEgJEwU>