Le chiffrement vous permet de vous assurer que seules les personnes recevant vos informations sont en mesure de les lire, mais il ne permet pas de s’assurer que vous êtes bien qui vous dites être. Un hacker peut parfaitement mettre en place un site qui utilise les formes les plus avancées de chiffrement, mais qui affiche une fausse identité aux visiteurs en leur faisant croire qu’ils communiquent avec quelqu’un d’autre. Le chiffrement de données n’est pas suffisant pour protéger vos visiteurs de toute personne malveillante.
Les certificats SSL délivrés par une Autorité de Certification fournissent aussi un service permettant de prouver que vous êtes bien qui vous annoncer. Les Autorités de Certification sont des fournisseurs établis avec une renommée et confiance mondiale. Une fois votre identité vérifiée par leurs services, ils ajouteront leur propre clé publique à votre certificat de manière à certifier à vos visiteurs que votre identité a été vérifiée et qu’elle fait part du processus de chiffrement.
Le degré de vérification de votre identité dépend du type de certificat que vous avez acheté. Un certificat standard se contente de vérifier un certain enregistrement dans les DNS de votre domaine afin de valider le contrôle que vous avez sur le domaine. Un certificat plus avancé vérifiera des enregistrements d’identification que vous fournirez. Les SSL les plus avancés sont les plus chers à l’achat, mais ce sont aussi ceux qui fourniront un degré de confiance plus élevé à vos clients qui vous confieront leurs données privées.
Des certificats numériques à jour sont essentiels pour protéger les données sensibles et connecter en toute sécurité appareils, machines et applications. Que se passe t il s’ils ne sont pas à jour ?
L’augmentation du nombre de certificats rend de plus en plus difficile leur gestion manuelle. Une mauvaise configuration ou l’absence d’alerte peut mener à une expiration non planifiée de certificat et à l’arrêt brutal des services. Oublier de renouveler un certificat sur un seul appareil ou serveur peut entraîner des failles de sécurité et des pertes de chiffres d’affaires.
Composants de base utilisés
Le programme de base de la gestion des keystores java le plus utilisé est keytool en mode commande.
En mode graphique le logiciel ikeyman permet de visualiser/gérer les keystores de différents formats.
Le programme de visualisation des certificats ou des csr (Certificate Signing Request) le plus utilisé est openssl.
On peut aussi utiliser le programme GNU certtool afin de disposer d’un outil avancé dans l’environnement Unix ou windows.
Ces programmes ont différents inconvénients :
- Beaucoup d’informations inutiles sont affichées (plusieurs lignes de valeurs en Hexa)
- Ces commandes ont une multitude de paramètres
- Les demandes de renouvellement ne sont pas tracées (qui ? quand ? en cours ? depuis combien de temps)
- Plusieurs demandes de csr peuvent être en conflits (plusieurs demandes en cours au niveau du PKI Public Key Infrastructure)
- L’administrateur et demandeur d’un renouvellement ne sera pas forcément présent au moment de la réception du certificat renouvelé par le service en charge du PKI
- Aucune normalisation imposée, chaque demandeur est laissé libre de sa demande
- Des erreurs de saisies ou oublis peuvent exister dans la demande de renouvellement
- Le nombre de jours restant n’est pas calculé automatiquement (date de péremption et nombre de jours restants)
- Aucune mise en valeur des anomalies par des couleurs lors de la visualisation ou les futurs changements
- La sécurité des certificats est assurée par un keystore/truststore avec un mot de passe qui n’est pas forcément connu
- Des certificats CA (Certificat Autorité) stockés hors de ces keystores ne doit pas être constaté.
- Lors d’un changement/intégration plusieurs fichiers peuvent être mis en œuvre (.sav, .new etc …)
- Une proposition de ménage (delete) est proposée dans ce cas à partir d’un fichier de properties
- Ce fichier de properties sert aussi à normaliser les demandes et les seuils d’alerte adapté aux bonnes pratiques
- Sous Unix on ne peut pas visualiser de manière aisée si le certificat dispose d’un UPN (User Principal Name)
- Avec les commandes de base (ikeyman, keystore, openssl, ) on ne peut regarder/contrôler qu’un seul certificat à la fois dans le détail.
- Le mot de passe du keystore/truststore/autre jks n’est pas forcément connu :
- Cependant il excite dans le fichier de configuration standalone-jok-web.xml par exemple pour jboss/wildfly ou chaque store peut avoir un mot de passe différent
<system-properties>
<property name=”evopajee.env” value=”INT”/>
<property name=”javax.net.ssl.truststorePassword” value=”password1″/>
<property name=”evopajee.application.name” value=”joker”/>
<property name=”javax.net.ssl.keyStore” value=”/home/joker/appli/jok/jboss-eap-joker-node1/configuration/keystore/https/https.keystore”/>
<property name=”javax.net.ssl.keyStorePassword” value=”password2″/>
<property name=”javax.net.ssl.truststore” value=”/home/joker/appli/jok/jboss-eap-joker-node1/configuration/keystore/https/https.truststore”/>
<property name=”javax.net.ssl.trustStorePassword” value=”password3″/>
<property name=”javax.net.ssl.trustStore” value=”/home/joker/appli/jok/jboss-eap-joker-node1/configuration/keystore/https/https.truststore”/>
</system-properties> - C’est-à-dire que dans le cas d’une application multi-instance vous multipliez par 2 ou 3 le nombre de mots de passe inconnus.
- Dans certaine application il existe aussi des keystores additionnels (Accès à MQSeries par exemple) dont le nom et l’emplacement ne sont pas connu.
Dans ce cas, celui-ci est trouvé à partir du fichier .xml de configuration ainsi que son emplacement et son mot de passe.
- Cependant il excite dans le fichier de configuration standalone-jok-web.xml par exemple pour jboss/wildfly ou chaque store peut avoir un mot de passe différent
- Dans le cas d’un mot de passe de keystore crypté par un programme vault, on peut réutiliser celui-ci afin de le décrypter et accéder ainsi au contrôle de son contenu.