Principe :

Lorsqu'une application, un site ou un webservice doit effectuer des échanges en HTTPS, le certificat du serveur web contacté doit :

• être valide,
• avoir un certificat racine connu des autorités de certification installées sur le PC, le Mac, le téléphone Android, la tablette Apple, le firmeware d'un objet connecté (...), qui exécute l'application.

Sans cela, le chiffrement de la connexion sera impossible avec par exemple le retour suivant lors d'un HTTPEnvoie, RESTEnvoie, HTTPRequete (cf. FAQ 20558) :
Erreur 100138
Une erreur système a été détectée pendant l'envoi de la requête HTTP.
Détail de l'erreur système : La vérification du certificat SSL ou de la clé SSH a échoué.

Exemple concret :

• une application WINDEV Mobile sous Android appel un webservice,
• le webservice est hébergé sur un serveur web doté d'un certificat Let's Encrypt dont le certificat racine est "ISRG Root X1" depuis le 30/9/2021,
• en fonction de la version de Android de l'appareil qui exécute l'application :
  • Android antérieures à la 7.1.1 (décembre 2016) : erreur "vérification du certificat SSL... a échoué" car ces anciennes versions de Android ne prennent pas en charge le certificat racine "ISRG Root X1",
  • Android 7.1.1 et toutes les suivantes : l'appel se fait normalement, le certificat racine "ISRG Root X1" est connu.

Solutions :

Voici les différentes solutions pouvant être appliquées lorsque le système client ne connaît pas le certificat racine du serveur web :

• Ajouter dans le système client qui exécute l'application l'autorité de certification qui n'est pas connue. Dans les réglages de Android, de iOS, ou dans les paramètres de Windows, des choix dédiés permettent l'ajout d'autorités de confiance lorsque l'éditeur ne fait plus de mise à jour automatique.
  Cette solution impose d'intervenir dans les réglages de chaque appareil ou du poste de travail, après avoir obtenu le certificat racine manquant.
  
  
• Ou faire connaître le certificat à l'application :
  
  • obtenir le certificat auprés de son éditeur, ou le télécharger avec un navigateur depuis Windows,
  • ajouter le certificat dans les fichiers à déployer avec l'application. Ce fichier peut également être intégré dans la librairie (fichier WDL) de l'application.
  • appeler en lui donnant le certificat la fonction CertificatDeConfianceAjoute. L'appel peut être fait dès le code d'initialisation du projet, ou en tout cas être placé avant l'exécution de la première requête HTTPS vers le serveur.
• Ou, remplacer sur le serveur web le certificat, par un nouveau dont le certificat racine sera connu de tous les systèmes qui doivent exécuter l'application. Dans le cas d'un serveur hébergé sur une plateforme de PCSCLOUD, l'installation du certificat se fera directement depuis le tableau de bord après demande d'un CSR.

Bon à savoir :

• Les certificats racines sont mis à disposition par leurs éditeurs sur leurs sites. Par exemple pour Let's Encrypt :
  https://letsencrypt.org/certificates/
  
  
• Il est toujours possible de télécharger le certificat racine utilisé pour chiffrer les échanges avec un serveur web :

  • dans un navigateur sous Windows, se connecter à une page quelconque du serveur en HTTPS afin d'afficher son certificat ("ISRG Root X1" pour l'exemple, il pourrait s'agir d'un tout autre certificat ou d'un certificat auto-signé pour un usage interne) :
    
    
    

  • dans la fenêtre système d'affichage du certificat, sélectionner "Chemin d'accès de certification",
    
    
    

  • sélectionner le certificat racine et clic sur "Afficher le certificat" :
    
    
    

  • puis dans le "Détail" du certificat bouton "Copier dans un fichier" :
    
    
    

  • dérouler l'assistant d'exportation afin d'obtenir un fichier .cer. Ce fichier contient le certificat racine. Il peut alors être ajouté dans les autorités de certification du système client, ou utilisé avec la fonction CertificatDeConfianceAjoute.

• Sous Windows on peut contrôler la présence du certificat dans les autorités de certification racines de confiance avec l'application CERTMGR ("Démarrer ... Exécuter" : CERTMGR.MSC) :
  
  
  

Cas exceptionnel de la "cross-signature" :
Il peut arriver qu'un certificat contienne plusieurs certificats racines. Ca a été le cas pour les certificats Let's Encrypt afin de gérer le passage du certificat racine initial "DST Root CA X3", au certificat actuel "ISRG Root X1". Dans ce cas, il faut que l'application qui contacte un serveur avec un tel certificat sache trouver le bon certificat à partir des chaînes de certification, notamment si l'un d'eux est révoqué. C'est le cas pour les applications WINDEV et WINDEV Mobile et les sites et webservices WEBDEV à partir de la version 25. Si l'appel est fait depuis une version antérieure du framework, il faut obligatoirement que le premier certificat racine trouvé soit valide et connu (cf. paramètre --preferred-chain "<certificat racine>" dans les étapes de génération du certificat).