Souverain

Ce que j’ai découvert derrière le HTTPS

Au départ, je ne pensais pas écrire un article sur un certificat SSL.
Pour être tout à fait honnête, je ne pensais même pas changer celui de ce site.
Comme beaucoup de personnes qui administrent un site internet sans être ingénieur, expert TLS ou administrateur système de métier, j’avais fait ce que l’on fait souvent quand l’option est disponible chez son hébergeur : j’avais cliqué et puis c’est tout !

Chez OVH, l’hébergeur de ce site, la solution Let’s Encrypt était proposée par défaut. Gratuit, automatique, facile à activer. Un bouton, un peu d’attente, et le site passait en mode HTTPS. Dans le genre expérience utilisateur, difficile de faire plus rassurant et plus facile. Pas besoin de terminal, pas besoin de comprendre ce qu’est une clé privée, pas besoin de savoir ce qu’est une chaîne de certificats : le cadenas apparaissait dans le navigateur, et tout semblait en ordre 🔒.

Pour le grand public (dont je fais partie), un certificat SSL, ou plus exactement TLS aujourd’hui, sert à sécuriser la connexion entre un site web et ses visiteurs. C’est lui qui permet au navigateur d’afficher le fameux cadenas HTTPS. Il contribue à chiffrer les échanges, à éviter qu’ils circulent en clair sur le réseau, et à établir une relation de confiance entre l’internaute et le site consulté. Sans ce certificat, un site reste en HTTP, les navigateurs le signalent davantage, et l’expérience inspire immédiatement moins confiance.

Dit comme cela, l’affaire paraît simple : un certificat, un cadenas, un site sécurisé. Sujet réglé. Merci et au revoir !

Le hic, c’est que cette quête de souveraineté numérique et d’autonomie a une fâcheuse tendance (de temps en temps, je dois bien le reconnaître) à transformer un détail technique en une question d’une ampleur considérable.

On tire un fil presque par curiosité, et l’on se retrouve à regarder une chaîne entière de dépendances que l’on n’avait pas forcément vues venir.

Dans mon cas, tout a commencé avec un test réalisé via l’excellent outil de Patrice Andreani : Indépendance. Le nom est limpide, presque évident, et l’outil l’est tout autant dans son intention. Il permet d’évaluer concrètement le niveau de dépendance technologique d’un site internet.

Indépendance repose sur six grands piliers :

• les dépendances externes,
• l’hébergement,
• le fournisseur DNS,
• le bureau d’enregistrement du nom de domaine,
• le certificat TLS,
• les courriels et les serveurs MX.

Autrement dit, l’outil ne se contente pas de demander si un site essaye de se la jouer souverain. Il regarde ce qui se passe réellement sous le capot : qui héberge, qui résout le nom de domaine, qui fournit le certificat, quels services externes sont appelés, par où passent les courriels.
Il y a dans cette démarche quelque chose de très sain. On quitte le discours général pour entrer dans la vérification technique. On ne parle plus seulement d’intention, mais de dépendances mesurables.

Et dans cette enquête un peu artisanale, plusieurs outils de test de souveraineté numérique sont passés entre mes mains. Certains donnent des indications utiles, d’autres permettent de repérer quelques dépendances techniques, mais aucun ne m’a paru aussi lisible, aussi complet et aussi directement exploitable que celui de Patrice. L’outil permet de comprendre pourquoi un site dépend de tel ou tel acteur, où se situent les points de fragilité, et comment une évaluation peut devenir un début de pédagogie plutôt qu’un simple score.

Autre point important : cette solution est gratuite, open source, et son code est disponible sur GitLab. Et ce n’est pas un détail. Le fait de publier le code permet à chacun de regarder la méthode, de l’auditer, d’avoir des échanges et de proposer des améliorations. Aussi, le fait que cela soit hébergé sur GitLab, et non sur GitHub, a pour moi une portée symbolique dans un contexte où GitHub appartient à Microsoft (même si j’utilise encore GitHub 🤦‍♂️). Cela ne règle pas toutes les questions, bien sûr, mais cela montre une certaine cohérence dans la démarche : l’outil ne demande pas seulement aux autres d’être transparents, il expose aussi sa propre éthique.

Enfin, cette transparence donne du poids à la démarche, surtout lorsqu’on prétend mesurer une partie de la souveraineté numérique.

L’histoire commençait donc plutôt bien.

Je me lance dans le test avec une confiance plutôt assumée. Enfin, disons avec cette petite prétention de celui qui pense avoir plutôt bien travaillé. Après tout, ce projet et ce site existent précisément pour interroger ces sujets. Il me semblait vraiment avoir pris la peine de vérifier beaucoup de points. Je m’attendais donc à un score plutôt élevé. Peut-être même à frôler la perfection. Rien que cela.

Humilité oblige, le résultat n’était pas exactement à la hauteur de mes espérances.

Le score n’était pas catastrophique, loin de là. Mais il n’était pas parfait. Et l’un des points bloquants venait du certificat TLS : il était fourni par Let’s Encrypt.

Sur le moment, je l’avoue, cela m’a surpris. Let’s Encrypt fait partie de ces services que l’on utilise sans trop se poser de questions, précisément parce qu’ils fonctionnent bien. Comme je souhaite à nouveau le rappeler, chez OVH, il suffisait juste de l’activer. Le certificat se mettait en place automatiquement. Le renouvellement était géré lui aussi automatiquement. Le site passait en HTTPS sans complication. Pour quelqu’un qui n’est pas spécialiste du sujet, c’est plutôt l’expérience idéale.

Je ne m’étais donc jamais vraiment demandé qui était derrière. Je savais vaguement que c’était important, que cela permettait d’avoir le cadenas HTTPS, que sans cela le site serait moins sécurisé. Mais, comme beaucoup, je pense, je m’étais arrêté là. Le certificat était gratuit, reconnu par les navigateurs, proposé par mon hébergeur, et tout fonctionnait.

À la suite de ce test, j’ai commencé à regarder Let’s Encrypt de plus près :

Let’s Encrypt est une autorité de certification gratuite, automatisée, très largement utilisée, opérée par l’ISRG, une organisation américaine à but non lucratif. Il serait injuste de nier son rôle historique dans la sécurisation du Web. Sans Let’s Encrypt, une quantité immense de petits sites, d’associations, de blogs, de médias indépendants ou de services auto-hébergés seraient probablement restés en HTTP, ou auraient dû gérer des certificats payants avec une complexité peu compatible avec leurs moyens.

Let’s Encrypt a démocratisé HTTPS. C’est un fait, et c’est à mettre à son crédit.

Mais en poursuivant mes recherches, un chiffre m’a interpellé : Let’s Encrypt représenterait plus de 60 % des certificats TLS observés sur le Web. Et là, forcément, je me suis dit : « Heu… c’est quand même beaucoup ! »

C’est à ce moment-là que commence (encore) une nouvelle question de dépendance.

À nouveau, il ne s’agit pas de faire un amalgame. Une technologie peut être très majoritaire sans être immédiatement problématique. Linux est lui aussi très présent sur les serveurs web, et cela ne m’inquiète pas pour autant. La question n’est donc pas seulement celle de la part de marché. Elle est aussi celle de la nature de la dépendance, de la gouvernance, du cadre juridique, de la possibilité réelle de changer, et du rôle joué par cette brique dans la confiance du Web.

Alors j’ai continué à creuser.

J’ai vite compris que Let’s Encrypt ne devait pas être caricaturé. Ce n’est pas Google Cloud, AWS ou Microsoft Azure. Ce n’est pas un service commercial classique qui enfermerait volontairement ses utilisateurs. Le projet repose sur des standards ouverts, notamment ACME, il est largement intégré, très documenté, et soutenu par un écosystème large.

Mais j’ai aussi compris que sa gratuité avait une contrepartie logique : le service ne fournit pas de contrat ni d’engagement de niveau de service opposable comme peut le faire une offre contractuelle payante. En cas de panne, de problème d’automatisation ou de difficulté critique, l’utilisateur assume l’essentiel du risque opérationnel. Ce n’est pas scandaleux : c’est gratuit. Mais c’est précisément ce qui mérite d’être compris lorsqu’on parle d’infrastructures critiques.

Il existe aussi des enjeux de conformité. Certaines organisations doivent justifier précisément leurs choix techniques, leurs dépendances, leur traçabilité et leur résilience, notamment dans des contextes réglementaires exigeants. Là encore, cela ne veut pas dire que Let’s Encrypt serait inadapté par nature. Cela signifie simplement que son modèle gratuit, automatisé, très efficace pour le Web ouvert, ne répond pas toujours aux mêmes besoins qu’une relation contractuelle avec une autorité de certification choisie, documentée et intégrée dans une politique de conformité.

Il y a enfin un risque plus opérationnel : la durée courte des certificats impose un renouvellement automatisé impeccable. Quand tout est bien configuré, cela fonctionne très bien. Mais dans certains environnements complexes, hybrides ou mal documentés, une rupture dans la chaîne d’automatisation peut provoquer des erreurs TLS en production. Sur un petit site, cela peut être gênant. Sur une infrastructure critique, cela peut devenir beaucoup plus sérieux.

Soyons clairs : cela ne signifie pas que Let’s Encrypt lit le trafic HTTPS de vos visiteurs. C’est une confusion fréquente que j’ai remarquée lors de mes recherches. Le certificat permet d’établir la confiance et de chiffrer la connexion : il ne donne pas automatiquement accès au contenu des communications. Le sujet de souveraineté n’est donc pas celui d’une surveillance directe du trafic. Il porte plutôt sur une dépendance juridique, opérationnelle et industrielle : qui émet, révoque, journalise, automatise, devient incontournable dans une couche aussi essentielle du Web ?

À ce stade de mes recherches, la conclusion n’était pas : « Let’s Encrypt est un problème. » Ce serait trop simpliste, et probablement injuste (d’autres pourraient me dire que c’est faux).

La conclusion était plutôt : « Let’s Encrypt est un service remarquable, mais sa place dominante mérite d’être interrogée lorsqu’on parle de souveraineté numérique. »

Et comme je suis curieux, que j’aime parfois mettre les mains dans le cambouis, et que j’ai cette fâcheuse tendance à vouloir comprendre les détails une fois que j’ai commencé à tirer le fil, alors, j’ai décidé de chercher une alternative.

C’est ici que mon « enquête » a pris une tournure un peu moins confortable.

Dans ma grande naïveté et n’étant ni journaliste spécialisé, ni expert en infrastructures de confiance, je pensais qu’il serait assez simple de trouver une autorité européenne, de demander un certificat, de remplacer Let’s Encrypt, et de passer à autre chose. Après tout, un certificat reste un certificat, non ?

Évidemment, non 😒

Plus je cherchais, plus je découvrais que le sujet était moins simple que prévu. Certaines offres étaient payantes. D’autres étaient difficiles à comprendre. Certaines autorités de certification semblaient sérieuses, mais les tarifs montaient vite. Au départ, je m’étais dit : s’il faut payer quelques euros pour la cohérence, pourquoi pas. Puis, au fil des recherches, les prix grimpaient, les conditions se complexifiaient, et je commençais à me dire que cette histoire de certificat gratuit activé par défaut m’avait peut-être rendu dépendant sans même m’en rendre compte.

C’est une sensation étrange : vous n’avez jamais vraiment choisi Let’s Encrypt, vous l’avez simplement activé parce que votre hébergeur vous le proposait, et lorsque vous voulez regarder ailleurs, vous découvrez que le confort du départ a créé une forme de réflexe et de dépendance.

C’est à ce moment-là que je suis revenu vers Patrice Andreani.

Avec beaucoup de simplicité, et en quelques heures à peine, il m’a indiqué une piste : Actalis.
Il a été très clair : il ne l’avait pas testée lui-même, mais la solution lui paraissait intéressante sur le papier. Cette précision est importante. Il ne m’a pas vendu une solution, il ne m’a pas promis que tout fonctionnerait, il m’a simplement orienté vers une option qui méritait d’être regardée.

Je ne connaissais pas Actalis, je suis donc allé voir : société italienne, autorité de certification européenne, rattachée au groupe Aruba, reconnue dans l’écosystème des certificats. Sur le papier, l’option avait de quoi retenir l’attention. Restait à comprendre si elle pouvait réellement répondre à mon besoin, et surtout si elle proposait une offre accessible.

Bonne nouvelle : Actalis propose bien une offre gratuite.

Mais nuance : je ne peux pas dire que cette offre gratuite m’ait sauté aux yeux immédiatement. Il a fallu chercher un peu. L’offre existe, mais elle n’a pas exactement l’évidence d’un gros bouton « certificat gratuit ici » au milieu de la page. À force de fouiller, j’ai fini par trouver l’URL directe du plan gratuit.

Là encore, l’expérience raconte quelque chose : Let’s Encrypt est devenu si intégré, si automatique, si présent dans les interfaces d’hébergement, que l’on oublie la différence entre une solution devenue standard de fait et une alternative encore peu connue du grand public. Actalis existe, l’offre gratuite aussi, mais le chemin pour y arriver demande déjà un peu plus de volonté.

Une fois cette piste trouvée, il fallait encore la comparer sérieusement.

Changer pour changer n’avait aucun intérêt. Remplacer Let’s Encrypt uniquement pour pouvoir dire que l’on a remplacé Let’s Encrypt n’aurait pas grand intérêt.
Le vrai sujet était de savoir ce qu’Actalis changeait réellement.

Actalis apporte d’abord un argument que Let’s Encrypt ne peut pas offrir : une autorité de certification européenne, italienne, intégrée à l’écosystème européen de la confiance numérique. Dans une réflexion sur la souveraineté numérique, ce n’est pas anecdotique. Le certificat TLS participe à la chaîne de confiance du site. Choisir l’autorité qui l’émet, ce n’est donc pas seulement choisir un prestataire technique : c’est aussi choisir un acteur qui intervient dans une brique fondamentale du Web.

Mais rigueur oblige !

Le certificat gratuit d’Actalis est un certificat DV, pour Domain Validation. Cela signifie qu’il prouve essentiellement le contrôle du domaine. Il ne valide pas fortement l’identité de l’organisation derrière le site, contrairement à d’autres catégories comme les certificats OV, EV ou certains certificats qualifiés. Autrement dit, le fait qu’Actalis soit une autorité européenne ne transforme pas automatiquement un certificat DV gratuit en certificat « souverain » au sens strict du terme.

Son intérêt est ailleurs.

Actalis montre qu’il existe une alternative européenne crédible, gratuite pour certains usages de base, compatible avec les standards du Web, et capable de fournir un certificat reconnu par les navigateurs. Mais cela ne remplace pas une stratégie complète d’autonomie.

Il faut aussi regarder les limites. Actalis n’a pas « l’universalité » pratique de Let’s Encrypt. Ce dernier est intégré presque partout : hébergeurs, panels, YunoHost, scripts, documentations, tutoriels. Toute une culture technique s’est construite autour de son usage. Actalis peut être utilisé avec ACME, mais la procédure n’a pas encore la même fluidité pour un utilisateur grand public. Dans mon cas, comme je passais par OVH et non par une automatisation complète, il a fallu générer un CSR, gérer une clé privée, valider le domaine, récupérer le certificat, extraire la chaîne intermédiaire, puis importer tout cela manuellement.

Autre limite : Actalis reste très petit face à Let’s Encrypt. Les statistiques de W3Techs donnent à Let’s Encrypt une part de marché supérieure à 60 % dans les certificats TLS, tandis qu’Actalis reste très loin derrière (~ 0,7%). Cela ne rend pas Actalis moins intéressant, mais cela rappelle que l’on ne remplace pas un standard de fait par un simple changement individuel et isolé. On teste une alternative, on documente une possibilité, on ouvre une voie. On ne renverse pas « un équilibre mondial » en changeant le certificat d’un site personnel.

Enfin, il ne faut pas idéaliser Actalis sous prétexte qu’il est européen. Une autorité européenne n’est pas automatiquement parfaite. Comme toutes les autorités de certification, elle doit être reconnue par les navigateurs, respecter des règles strictes, être auditée, corriger ses éventuels incidents, et maintenir la confiance dans la durée. La souveraineté numérique ne consiste pas à remplacer une dépendance américaine par une confiance aveugle dans n’importe quel acteur européen. Elle consiste plutôt à choisir en connaissance de cause, avec des critères explicites, des limites identifiées, et une capacité de vérification.

À ce stade, ma décision était prise.

Non, Let’s Encrypt n’était pas devenu l’ennemi.
Non, Actalis n’était pas une solution parfaite.
Non, je n’allais pas résoudre la souveraineté numérique du Web avec un simple certificat TLS.

Mais l’expérience valait la peine d’être menée.

D’abord parce qu’elle permettait de tester concrètement une alternative européenne. Ensuite parce qu’elle obligeait à comprendre ce que l’on manipule réellement lorsque l’on parle de ce sujet. Enfin parce qu’elle pouvait servir à d’autres : celles et ceux qui, comme moi, ne sont pas spécialistes du sujet, mais veulent comprendre comment passer d’un constat de dépendance à une action technique concrète.

C’est donc à ce moment-là que l’histoire bascule vers le tutoriel.

Et là, les choses se sont révélées un peu plus sportives que prévu.

Il a fallu :

• générer une demande de certificat,
• comprendre la différence entre un CSR et une clé privée,
• choisir la bonne méthode de validation,
• ajouter une entrée TXT chez OVH,
• corriger une erreur liée aux noms de domaine,
• découvrir que le certificat couvrait finalement le domaine et le www,
• récupérer les fichiers fournis par Actalis,
• extraire la chaîne intermédiaire depuis un fichier .p7b,
• supprimer l’ancien certificat Let’s Encrypt chez OVH avant de pouvoir importer le nouveau,
• attendre que l’interface OVH se mette à jour,
• puis vérifier en ligne de commande que le site servait bien le certificat Actalis.

Autrement dit : exactement le genre d’opération que l’on imagine simple tant qu’on ne l’a pas faite soi-même.

Cet article raconte donc une bascule réelle, avec ses hésitations, ses erreurs, ses messages d’alerte, ses délais d’attente et ses vérifications. Ce n’est surtout pas un guide « certifié » écrit depuis une documentation officielle.
C’est un retour d’expérience concret : comment ce site est passé de Let’s Encrypt à Actalis, pourquoi cette démarche peut avoir du sens dans une réflexion sur la souveraineté numérique, et quelles précautions prendre avant de se lancer.

Tutoriel : remplacer Let’s Encrypt par Actalis chez OVH, sans perdre le HTTPS en route

Avant d’entrer dans le détail, je préfère apporter une précision importante : il ne s’agit pas là d’une procédure universelle applicable à tous les hébergeurs, à toutes les configurations ou à toutes les autorités de certification. Mais elle peut servir de base très concrète à celles et ceux qui veulent comprendre ce qui se passe réellement lorsqu’on remplace un certificat TLS automatique par un certificat personnalisé.

Dans mon cas, le point de départ était simple :

• le domaine était géré chez OVH
• le site était hébergé chez OVH
• Let’s Encrypt était déjà activé
• le site fonctionnait correctement en HTTPS
• l’objectif était de remplacer ce certificat par un certificat Actalis
• le certificat devait couvrir à la fois le domaine principal et sa version avec www.

Sur le papier, cela paraît raisonnable. Dans la pratique, il a fallu avancer avec méthode.

Comprendre ce qu’Actalis me demande : un CSR, pas une clé privée

La première étape consiste à demander un certificat chez Actalis.

Dans le formulaire, Actalis propose plusieurs options, dont la génération automatique d’un CSR. Pour rester dans une logique de maîtrise, j’ai préféré ne pas laisser un tiers générer cette demande à ma place.

Le bon choix, dans mon cas, était donc de cocher la case J’ai déjà un fichier CSR.
Un CSR, pour Certificate Signing Request, est une demande de certificat. Il contient notamment le nom de domaine concerné et une clé publique. En revanche, il ne contient pas la clé privée.

C’est un point essentiel : la clé privée doit rester sous votre contrôle.

Le principe est donc le suivant :

• CSR → transmis à Actalis
• clé privée → conservée par vous

ATTENTION : La clé privée ne doit pas être envoyée à Actalis. Elle servira plus tard, au moment de l’import du certificat chez OVH.

Générer la clé privée et le CSR

Sur macOS, j’ai utilisé le Terminal et OpenSSL.
J’ai d’abord créé un dossier dédié :

mkdir -p ~/certificats-souverain
cd ~/certificats-souverain

Puis j’ai généré un premier fichier de configuration pour créer un CSR.

Au départ, j’ai tenté de générer un CSR couvrant à la fois :

souverain.ovh
www.souverain.ovh

Techniquement, cela avait du sens. Beaucoup de certificats TLS modernes utilisent des SAN, (pour Subject Alternative Names), afin de couvrir plusieurs noms dans un même certificat.
Mais Actalis m’a renvoyé une erreur : « Nombre de champs SAN non valide pour un seul hôte »
Traduction : pour ce type de demande, Actalis ne voulait pas de plusieurs noms dans le CSR.

J’ai donc refait un CSR uniquement pour mon domaine principal, c’est-à-dire : souverain.ovh avec cette configuration :

cat > csr-souverain-seul.conf <<'EOF'
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
C = FR
CN = souverain.ovh

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = souverain.ovh
EOF

openssl req -new -nodes -newkey rsa:2048 \
-keyout souverain.ovh-single.key \
-out souverain.ovh-single.csr \
-config csr-souverain-seul.conf

Cette commande crée deux fichiers :

• souverain.ovh-single.key → la clé privée
• souverain.ovh-single.csr → la demande de certificat

ATTENTION : Le fichier le plus sensible est la clé privée, c’est-à-dire : souverain.ovh-single.key
Il ne faut pas la publier, ne pas la coller dans Actalis, ne pas la partager dans une capture d’écran, ne pas l’envoyer par courriel.

Vérifier le contenu du CSR

Avant de copier le CSR dans Actalis, j’ai vérifié qu’il contenait bien uniquement le domaine attendu :

openssl req -in souverain.ovh-single.csr -noout -text | grep -A2 "Subject Alternative Name"

Le résultat devait afficher :

X509v3 Subject Alternative Name:
DNS:souverain.ovh

C’est seulement après cette vérification que j’ai copié le CSR :

cat souverain.ovh-single.csr | pbcopy

Sur macOS, la commande ne renvoie rien dans le Terminal. C’est normal : elle copie simplement le contenu dans le presse-papiers.

Ensuite, dans Actalis, il faut coller ce bloc dans le champ CSR. Il commence par :
—–BEGIN CERTIFICATE REQUEST—–
et se termine par :
—–END CERTIFICATE REQUEST—–

Choisir la validation DNS chez Actalis

Actalis propose plusieurs méthodes de validation du domaine. Dans mon cas, j’ai choisi la validation par enregistrement TXT DNS. C’est la méthode la plus propre lorsqu’on gère son domaine chez OVH, car elle consiste simplement à prouver que l’on contrôle la zone DNS du domaine.

Actalis m’a demandé d’ajouter une entrée TXT de ce type :

actalis-dcv=xxxxxxxxxxxxxxxxxxxx

Chez OVH, il faut aller dans :
Domaines → votre nom de domaine → Zone DNS → Ajouter une entrée → TXT

Puis renseigner :

Sous-domaine : @
Type : TXT
Valeur : actalis-dcv=xxxxxxxxxxxxxxxxxxxx
TTL : par défaut

Le @ signifie que l’entrée est placée à la racine du domaine.

Une fois l’entrée ajoutée, il faut patienter un peu, puis vérifier qu’elle est bien visible publiquement :

dig TXT souverain.ovh +short

Dans mon cas, le résultat affichait bien l’entrée Actalis :

"actalis-dcv=..."

À ce moment-là seulement, il était possible de retourner chez Actalis et de poursuivre la validation.

Recevoir le certificat Actalis

Après validation, Actalis m’a envoyé un courriel indiquant que le certificat était émis. Dans ce courriel, il y avait plusieurs éléments importants. D’abord, des codes de gestion et de révocation. Ces informations doivent rester privées. Elles ne doivent pas être publiées dans une capture d’écran ou dans un article. Ensuite, Actalis fournissait deux fichiers ZIP.
Dans mon cas, les fichiers contenaient :

• Le fichier .cer correspond au certificat serveur.
• Le fichier .p7b contient la chaîne de certificats, c’est-à-dire les éléments permettant de relier le certificat serveur à l’autorité de certification reconnue par les navigateurs.

À ce stade, le formulaire d’OVH ne peut pas encore être rempli au hasard. Il faut identifier précisément les trois éléments nécessaires :

• le certificat serveur
• la clé privée
• la chaîne de certificats

Extraire et vérifier le certificat reçu

J’ai d’abord extrait le fichier .cer :

unzip -o ~/Downloads/"CCR Certificats Souverain"/Certificato_*.zip -d .

Puis j’ai vérifié son contenu :

openssl x509 -in Certificato_*.cer -noout -subject -issuer -dates -ext subjectAltName

Et là, bonne surprise : même si le CSR ne contenait que souverain.ovh, le certificat émis par Actalis couvrait finalement les deux noms :

• DNS:www.souverain.ovh
• DNS:souverain.ovh

Cela signifie que, dans mon cas, une seule demande Actalis suffisait pour couvrir souverain.ovh ainsi que www.souverain.ovh

C’est un point important, car au départ je pensais devoir faire deux demandes séparées.

Vérifier que le certificat correspond bien à la clé privée

Avant d’importer quoi que ce soit chez OVH, il fallait vérifier que le certificat reçu correspondait bien à la clé privée générée au départ.

J’ai utilisé cette commande :

openssl x509 -noout -modulus -in Certificato_*.cer | openssl md5 && \
openssl rsa -noout -modulus -in souverain.ovh-single.key | openssl md5

Le but n’est pas d’utiliser la fonction MD5 pour sécuriser quoi que ce soit. Ici, le calcul demandé sert uniquement à comparer deux empreintes locales. Les deux lignes doivent être identiques.
Dans mon cas, elles l’étaient. Cela confirmait que le certificat Actalis reçu correspondait bien à ma clé privée.

Convertir le fichier .p7b en chaîne de certificats exploitable

OVH demande une chaîne de certificats dans un format texte compatible.

J’ai donc extrait le fichier .p7b :

unzip -o ~/Downloads/"CCR Certificats Souverain"/Certificate_*.zip -d .

Puis je l’ai converti en PEM :

openssl pkcs7 -inform DER -in Certificate_*.p7b -print_certs -out actalis-chain-from-p7b.pem

Ensuite, j’ai vérifié qu’il contenait bien des certificats :

grep "BEGIN CERTIFICATE" actalis-chain-from-p7b.pem

Dans mon cas, il y avait deux certificats et j’ai vérifié lesquels :

grep -E "subject=|issuer=" actalis-chain-from-p7b.pem

Le fichier contenait :

Actalis Domain Validation Server CA G3
souverain.ovh

Pour OVH, il fallait isoler uniquement le certificat intermédiaire :

awk 'BEGIN{n=0} /-----BEGIN CERTIFICATE-----/{n++} n==1{print} /-----END CERTIFICATE-----/ && n==1{exit}' actalis-chain-from-p7b.pem > actalis-intermediate.pem

Puis vérifier :

openssl x509 -in actalis-intermediate.pem -noout -subject -issuer

Le résultat devait correspondre à l’autorité intermédiaire Actalis :

subject=... CN=Actalis Domain Validation Server CA G3
issuer=... CN=Actalis Authentication Root CA

Renommer les fichiers pour éviter les erreurs

Avant l’import dans OVH, j’ai créé des copies avec des noms plus explicites :

cp Certificato_*.cer actalis-souverain.ovh-certificat.cer
cp souverain.ovh-single.key actalis-souverain.ovh-cle-privee.key
cp actalis-intermediate.pem actalis-souverain.ovh-chaine-ca.pem

À ce stade, les trois fichiers nécessaires étaient prêts :

• actalis-souverain.ovh-certificat.cer → certificat SSL
• actalis-souverain.ovh-cle-privee.key → clé privée
• actalis-souverain.ovh-chaine-ca.pem → chaîne CA / intermédiaire

Importer le certificat personnalisé chez OVH

C’est ici que les choses se sont compliquées. Dans OVH, il faut aller dans :
Web Cloud → Hébergements → votre hébergement → Certificats SSL
Puis cliquer sur : Import de votre propre certificat SSL. OVH demande alors trois champs :

• le certificat
• la clé privée non chiffrée
• la chaîne de certificats

J’ai donc copié successivement les trois fichiers.

Pour le certificat :

cat actalis-souverain.ovh-certificat.cer | pbcopy

Pour la clé privée :

cat actalis-souverain.ovh-cle-privee.key | pbcopy

Pour la chaîne de certificats :

cat actalis-souverain.ovh-chaine-ca.pem | pbcopy

Chaque contenu doit être collé dans le bon champ OVH.

Mais au moment de valider, OVH a refusé l’import. La raison était simple : Let’s Encrypt était encore actif sur le domaine.

Le piège OVH : supprimer Let’s Encrypt avant d’importer Actalis

C’est probablement le point le plus important de tout ce tutoriel. Chez OVH, il ne suffit pas d’importer le nouveau certificat par-dessus l’ancien. Si Let’s Encrypt est encore actif sur le domaine concerné, l’import peut échouer. Dans mon cas, il a fallu désactiver le certificat Let’s Encrypt déjà présent.
Première tentative : j’ai désactivé SSL sur le domaine principal, c’est-à-dire : souverain.ovh
Puis j’ai attendu que l’interface OVH se mette à jour.
L’entrée a fini par disparaître, mais l’import Actalis échouait encore. Pourquoi ? Parce que le certificat Let’s Encrypt était encore actif sur : www.souverain.ovh
Il a donc fallu désactiver également SSL sur www.souverain.ovh.
C’est un moment un peu délicat, car on touche à un site en production. Il peut y avoir une courte période pendant laquelle le HTTPS n’est pas encore correctement rétabli. Il vaut mieux ne pas faire cela dans la précipitation, et éviter de multiplier les manipulations dans tous les sens.

La bonne séquence, dans mon cas, a été :

• désactiver SSL sur souverain.ovh
• attendre que l’interface OVH se mette à jour
• désactiver SSL sur www.souverain.ovh
• attendre à nouveau
• relancer l’import du certificat Actalis

Hourra !

Après cette seconde désactivation, l’import a finalement été accepté.

Attendre OVH : l’interface ne se met pas à jour immédiatement

Même après validation de l’import, tout n’a pas été instantané. Pendant un moment, l’interface OVH ne montrait pas encore clairement le nouveau certificat. De mon côté, les lignes liées à l’ancien certificat ne disparaissaient pas immédiatement, et l’état affiché n’était pas parfaitement synchronisé avec la réalité.

J’ai donc vérifié directement ce que le site servait réellement comme certificat.

Première vérification :

echo | openssl s_client -connect souverain.ovh:443 -servername souverain.ovh 2>/dev/null | openssl x509 -noout -subject -issuer -dates

À un moment intermédiaire, le site servait encore un certificat OVH mutualisé :

subject=CN=cluster129.hosting.ovh.net
issuer=Let's Encrypt

Ce n’était pas encore bon, mais cela ne signifiait pas forcément que l’opération avait échoué. OVH était simplement encore en train de propager la nouvelle configuration.

Il a fallu attendre.

Puis, après quelques minutes, le bon certificat est apparu :

subject=CN=souverain.ovh
issuer=... Actalis Domain Validation Server CA G3

L’interface OVH a fini elle aussi par afficher le certificat comme actif, avec :

Type : Custom
Domaine principal : souverain.ovh
SAN : www.souverain.ovh
État : Actif

Le petit + visible dans l’interface OVH indiquait simplement que le certificat couvrait aussi un nom supplémentaire, ici www.souverain.ovh.

Vérifier le domaine principal et le www

Dernière étape : vérifier que les deux noms servent bien le certificat Actalis.

Pour le domaine principal :

echo | openssl s_client -connect souverain.ovh:443 -servername souverain.ovh 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Pour le www :

echo | openssl s_client -connect www.souverain.ovh:443 -servername www.souverain.ovh 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Dans les deux cas, le résultat devait afficher :

issuer=... Actalis Domain Validation Server CA G3

C’est seulement à ce moment-là que l’on peut considérer que la bascule est réellement terminée.

Ce qu’il faut retenir avant de se lancer

Cette opération m’a appris plusieurs choses. D’abord, il ne faut jamais perdre la clé privée. Dans mon cas, elle était contenue dans actalis-souverain.ovh-cle-privee.key
Sans cette clé, le certificat reçu ne peut pas être utilisé correctement.
Ensuite, il ne faut jamais exposer cette clé privée. Pas de capture d’écran, pas de copie dans un document public, pas d’envoi par courriel.

Il faut aussi conserver les trois fichiers finaux :

• actalis-souverain.ovh-certificat.cer
• actalis-souverain.ovh-cle-privee.key
• actalis-souverain.ovh-chaine-ca.pem

Autre point important : le certificat Actalis obtenu dans cette procédure est valable environ 90 jours. Dans mon cas, il expirait le 29 août 2026.

C’est un point essentiel, car OVH ne renouvellera probablement pas automatiquement un certificat personnalisé importé manuellement comme il le faisait avec Let’s Encrypt.

Il faudra donc prévoir un renouvellement avant l’expiration depuis l’interface d’administration de mon espace sur Actalis.

Enfin, l’entrée DNS TXT utilisée pour la validation Actalis peut rester en place. Elle ne gêne pas le fonctionnement du site. Elle peut même être utile en cas de renouvellement ou de nouvelle validation.

Au final, cette bascule n’a rien changé pour le visiteur, mais

Le site s’ouvre toujours en HTTPS. Le cadenas est toujours là. Les pages se chargent normalement. Personne, en arrivant ici, ne se dit : « Tiens, ce certificat TLS a l’air plus européen que ce matin. » L’objectif n’était pas de rendre le site plus spectaculaire, l’objectif était beaucoup plus simple : comprendre une dépendance, tester une alternative, documenter la procédure, et voir si cette alternative pouvait fonctionner concrètement chez OVH.
La réponse est oui.
Pour autant, cette bascule valait la peine. Elle m’a obligé à comprendre ce que je faisais. Elle m’a permis de remplacer un choix par défaut par un choix assumé. Elle m’a aussi donné matière à écrire cet article et ce tutoriel, avec les erreurs, les attentes, les détours et les petites surprises qui ne figurent pas toujours dans les documentations officielles.

Et puis il y a le résultat, très concret.

Depuis cette modification, j’obtiens 100 points sur 100 au test Indépendance de Patrice.
Ce n’est ni un diplôme, ni une certification, ni une garantie absolue. Un score reste un indicateur, pas une vérité gravée dans le marbre. Mais après avoir tiré ce fil, compris le problème, suivi la piste Actalis, traversé l’import OVH et vérifié le certificat en ligne de commande, voir ce 100/100 apparaître a eu une saveur particulière.

Cette histoire avait commencé par un clic presque machinal sur une option par défaut. Elle se termine avec une brique technique mieux comprise, un choix plus assumé, et cette petite satisfaction que procure une dépendance que l’on a enfin réussi à regarder en face.

Un remerciement particulier à Patrice Andreani, d’abord pour avoir développé son outil « Indépendance », mais aussi pour avoir pris le temps d’entendre mes questions, mes critiques, et de m’orienter vers la piste Actalis qui a rendu ce test possible.

Si des spécialistes voient dans cette démarche des erreurs, des limites ou une méthode plus simple pour atteindre le même résultat, leurs remarques sont les bienvenues : ce tutoriel ne prétend pas être une procédure dans les règles de l’art, mais une tentative documentée, perfectible, et ouverte à la discussion.

Enfin, si ce retour d’expérience peut aider d’autres personnes à comprendre ce qu’il y a derrière leur cadenas HTTPS, alors ce petit détour par les certificats TLS aura largement valu le temps passé.