Le 02/03/2018 à 19h 00

Il faut tout de même savoir qu’une AC n’a en aucun cas besoin de la clé privée d’un client pour lui délivrer son certificat. Ce qui laisse supposer que Trustico devait proposer un service de génération de biclé et de CSR, probablement bien pratique pour certains mais au détriment de la sécurité… car il ne faut jamais, au grand jamais, confier sa clé privée à qui que ce soit, on voit là le résultat.
Le bon conseil est donc de fuir toute société qui propose un service de génération de biclé (souvent présenté comme un générateur de CSR) en ligne (openssl le fait très bien) car il est impossible de savoir ce qui peut bien être conservé… même si après on vous livre le certificat et la clé privée dans un PKCS#12 avec un mot de passe long comme le bras qui fait très sécurisé. Si on vous fourni votre clé privée, elle n’est déjà plus privée !

 Après il serait peut-être intéressant de détailler un peu cette histoire de refus des certificats Symantec par Chrome car apparemment Chrome 66 et Firefox 60 vont bloquer l’accès à des milliers de sites s’ils ne remplacent pas leurs certificats avant le 17 avril, c’est explique ici :https://ssl-tls.info/symantec_thawte_geotrust_rapidssl.html

Le 13/02/2016 à 20h 04

Deux ou trois petites précisions.
L’article parle des alternatives gratuites antérieures à Let’s Encrypt mais il ne précise pas le coût des premières offres payantes alors que l’on trouve facilement des certificats à moins de 10 € par an, il y a d’ailleurs des brokers dans le domaine :https://www.namecheap.com/security/ssl-certificates/domain-validation.aspx
Donc le coût n’est pas réellement un obstacle à la mise en place de HTTPS l’hébergement chez un professionnel étant en général bien plus onéreux, mais comme le précise l’article c’est bien plus rapide (et il y a moins de risque de se tromper) avec une solution entièrement automatisée comme Let’s Encrypt.
Il faut également noter que jusqu’à présent disposer d’un hébergement en HTTPS signifiait également disposer d’une IPv4 en propre, mais avec la pénurie d’IPv4 et HTTPS devenant la norme il n’est plus envisageable de continuer de la sorte.
Il est parfaitement possible d’héberger plusieurs sites en HTTPS sur une même IP mais cela nécessite d’utiliser uniquement TLS et non plus SSLv3, plus précisément l’hébergement mutualisé repose sur l’extension du protocole TLS nommée SNI (Server Name Indication)https://fr.wikipedia.org/wiki/Server_Name_Indication
Pour que cela fonctionne il faut donc le client HTTPS dispose de TLS 1.0 minimum ce qui n’était pas le cas avec de très vieux clients Web comme IE 6. Utiliser SSLv3 en 2016 serait une très mauvaise idée sauf à avoir un besoin impérieux d’une rétrocompatibilité très étendue, d’un point de vue sécurité il est largement préférable d’utiliser TLS aujourd’hui et même TLS 1.2 plutôt que le 1.0 dont les suites cryptographiques commencent à donner des signes de fatigue cf. http://www.24joursdeweb.fr/2015/le-reveil-de-la-crypto-forte/ ainsi que le très bon wiki de Mozilla concernant la configuration TLS :https://wiki.mozilla.org/Security/Server_Side_TLS

Pour finir l’article indique « une connexion sécurisée (HTTPS) affichant le fameux cadenas, reposant
sur un chiffrement asymétrique avec un couple de clefs publique/privée
dont il faut s’assurer de l’origine » ce n’est pas tout à fait exacte sans être faux car avec SSL/TLS le chiffrement asymétrique n’est utilisé que dans la phase initiale pour échanger une clé de chiffrement symétrique (bien plus rapide), les algorithmes de chiffrement comme 3DES, RC4, AES ou ChaCha20 sont bien symétriques et ce sont bien eux qui sont à l’œuvre pour chiffrer une session HTTPS (et idéalement on ne devrait utiliser que les deux derniers).