Petit problème sur la génération de certificats let's encrypt wildcard avec acme.sh sur des domaines de deuxième niveau

[Mic13710]

Salut à tous,

Je m'occupe des NAS d'un ami. L'un est chez lui, l'autre est dans son entreprise.

N'ayant qu'un seul ndd hébergé chez OVH, j'ai créé des "sous-domaines" qui pointent chacun vers l'un des NAS. Pas de wildcard, mais des domaines bien définis à coup de CNAME dans la zone. Tout ça fonctionne très bien et le renouvellement de chaque certificat se fait sans problème.

Je souhaite maintenant passer par des certificats wildcard sur les deux sites. J'ai donc créé deux enregistrements CNAME : *.sub1.ndd.net et *.sub2.ndd.net

J'ai les API correspondantes pour sub1.ndd.net et sub2.ndd.net

Mais lorsque je tente de créer un certificat avec acme.sh, le processus bloque parce qu'il n'arrive pas a créer l'enregistrement TXT.

En analysant les logs, il s'avère qu'acme.sh n'identifie pas correctement le nom de domaine qu'il considère comme étant 'net'.

Voici un extrait du log avec mes commentaires :

[Sat Oct 31 18:13:12 UTC 2020] _sub_domain='_acme-challenge.sub1.ndd' (devrait-être '_acme-challenge' seulement)
[Sat Oct 31 18:13:12 UTC 2020] _domain='net' (devrait-être 'sub1.ndd.net')
[Sat Oct 31 18:13:12 UTC 2020] Adding record
[Sat Oct 31 18:13:12 UTC 2020] domain/zone/net/record (devrait-être domain/zone/sub1.ndd.net/record)
[Sat Oct 31 18:13:12 UTC 2020] GET
[Sat Oct 31 18:13:12 UTC 2020] url='https://eu.api.ovh.com/1.0/auth/time'
[Sat Oct 31 18:13:12 UTC 2020] timeout=30
[Sat Oct 31 18:13:12 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g --connect-timeout 30'
[Sat Oct 31 18:13:12 UTC 2020] ret='0'
[Sat Oct 31 18:13:12 UTC 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)'
[Sat Oct 31 18:13:12 UTC 2020] data='{"fieldType":"TXT","subDomain":"_acme-challenge.sub1.ndd","target":"7HpvWs7RaFcx6wQ0k3Nd5TP2-SSKiVYUZMlSrS_ZnRA","ttl":60}' (devrait-être 'acme-challenge' seulement)
[Sat Oct 31 18:13:12 UTC 2020] POST
[Sat Oct 31 18:13:12 UTC 2020] _post_url='https://eu.api.ovh.com/1.0/domain/zone/net/record' (devrait-être 'https://eu.api.ovh.com/1.0/domain/zone/sub1.ndd.net/record')
[Sat Oct 31 18:13:12 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g '
[Sat Oct 31 18:13:13 UTC 2020] _ret='0'
[Sat Oct 31 18:13:13 UTC 2020] Add txt record error.
[Sat Oct 31 18:13:13 UTC 2020] Error add txt for domain:_acme-challenge.sub1.ndd.net
[Sat Oct 31 18:13:13 UTC 2020] _on_issue_err

Du coup, il n'est pas possible d'obtenir un certificat wildcard pour chaque NAS.

Je pense que le souci vient de acme.sh

Pour contourner la chose, je me dis que plutôt que de faire un certificat par sous-domaine, il est aussi possible de faire un certificat sur ndd.net tout en conservant les deux wildcard.

La création du certificat serait alors de la forme :

acme.sh --issue --keylength 4096 -d 'ndd.net' -d 'sub1.ndd.net' -d '*.sub1.ndd.net' -d 'sub2.ndd.net' -d '*.sub2.ndd.net' --dns dns_ovh

Je pourrais alors obtenir un certificat que je pourrais importer du NAS1 vers le NAS2, mais je voudrais que les processus restent indépendants.

Dans ce cas, il faudrait que j'utilise le même processus de création sur l'autre NAS, mais alors, que devient l'enregistrement TXT du premier NAS, et surtout comment pourra se faire le renouvellement si l'enregistrement n'est plus le même ?

Si vous avez des idées, je suis preneur.

[Einsteinium]

Un wildcard c'est un wildcard... cela concerne tout le domaine... donc il faudra faire :

acme.sh --issue --keylength 4096 -d 'ndd.net' -d '*.ndd.net' --dns dns_ovh

Et faire ensuite l'import sur le second nas... ou alors modifier le hook d'importation de acme.sh et mettre une boucle pour que le script fassent les deux nas.

L'enregistrement n'est que temporaire et ce retrouve supprimé après validation 😉

[Mic13710]

Là pour le coup, je ne suis pas d'accord avec toi. Le wildcard peut s'appliquer à un "sous-domaine". Je n'ai d'ailleurs eu aucun problème pour créer mes deux enregistrements. L'essentiel c'est que le caractère '*' soit situé à gauche du nom de domaine.

Pour reprendre Fenrir, un sous domaine n'existe pas. donc ndd.net est un domaine, sub1.ndd.net est aussi un domaine.

Je n'ai pas de wildcard sur ndd.net car je n'utilise pas directement ce nom de domaine, mais même si j'en mettais un, ce n'est pas pour autant qu'il pourrait couvrir les requêtes sur sub1.ndd.net puisqu'il existe un enregistrement A sur ce dernier qui peut-être résolu. De même qu'il en existe un sur sub2.ndd.net. La priorité c'est d'abord les enregistrements existants, et si la requête ne peut pas aboutir, alors c'est le wildcard qui intervient.

En l’occurrence, mes wildcard se trouvent sur les domaine sub1.ndd.net et sub2.ndd.net qui sont parfaitement résolus. D'ailleurs, lorsque je demande sur https://www.whatsmydns.net par exemple si toto.sub1.ndd.net ou xxx.sub1.ndd.net existent, il n'y a aucun problème : ces adresses sont bien dirigées vers l'IP publique du NAS 1. Idem, pour mon sub2.ndd.net où les requêtes sont bien redirigées vers l'IP publique du NAS 2. Par contre, ce même site est incapable de résoudre ndd.net car je n'ai pas d'enregistrement dans ma zone pour cette url.

Le souci vient de acme.sh qui ne prend pas le bon site pour la création du TXT, ce qui bloque le processus de création du certificat.

On pourrait faire le parallèle avec les adresses synology.me qui ont des wildcards en pagaille puisque les adresses sont de la forme 'cequ'onveut.synology.me' et le wildcard correspondant étant '*.cequ'onveut.synology.me'

Il y a 13 heures, Einsteinium a dit :

L'enregistrement n'est que temporaire et ce retrouve supprimé après validation

Pas sûr que l'enregistrement TXT soit supprimé après validation. Pour mes propres domaines chez OVH et Gandi, les TXT qui ont été créés sont toujours dans mes zones. Mais il est possible qu'ils soient recréés à chaque renouvellement.

[Einsteinium]

il y a 11 minutes, Mic13710 a dit :

Le souci vient de acme.sh qui ne prend pas le bon site pour la création du TXT, ce qui bloque le processus de création du certificat.

Moi je suis partie du principe que acme ne prend pas les sous domaine en wildcard, si cela à évoluer alors tant mieux.

il y a 11 minutes, Mic13710 a dit :

Pas sûr que l'enregistrement TXT soit supprimé après validation. Pour mes propres domaines chez OVH et Gandi, les TXT qui ont été créés sont toujours dans mes zones. Mais il est possible qu'ils soient recréés à chaque renouvellement.

acme.sh supprime les enregistrements après validation si on utilise les api de dns (chez ovh en tout cas), ils ne sont inscrits que temporairement le temps de la validation. (si tu as les log : _clearupdns, Removing DNS records.)

[.Shad.]

Pourquoi vouloir créer deux certificats différents ?

Si je comprends bien, tu as :

sub1.ndd.net     A     IP_publique_NAS1
sub2.ndd.net     A     IP_publique_NAS2
*.sub1.ndd.net.     CNAME     sub1.ndd.net.
*.sub2.ndd.net.     CNAME     sub2.ndd.net.

Ici dans ton cas, tu peux très bien laisser ndd.net pointer en A sur l'hébergement par défaut d'OVH, ce n'est pas important.
Surtout tu ne mets pas d'enregistrement *.ndd.net, car tout ne pointe pas vers la même IP.
Ton certificat sera valide pour tes deux NAS.
Et tu ne changes pas la ligne de commande pour acme.sh

donc :

acme.sh --issue --keylength 4096 -d 'ndd.net' -d '*.ndd.net' --dns dns_ovh

acme.sh se fiche de savoir vers quoi tes enregistrements pointent, lui il vérifie que la zone t'appartient, et donc que les credentials que tu lui donnes lui permettent effectivement d'ajouter et supprimer les record _acme.challenge.

Si les enregistrements ne sont pas effacés, c'est qu'il y a un souci avec la commande DELETE pour l'API, j'utilise les permissions suivantes pour mon token et ça marche très bien :

GET /domain/zone/
GET /domain/zone/{domain.ext}/status
GET /domain/zone/{domain.ext}/record
GET /domain/zone/{domain.ext}/record/*
POST /domain/zone/{domain.ext}/record
POST /domain/zone/{domain.ext}/refresh
DELETE /domain/zone/{domain.ext}/record/*

Source

[Mic13710]

Merci à tous les deux.

il y a 13 minutes, .Shad. a dit :

Pourquoi vouloir créer deux certificats différents ?

Parce que c'est le cas actuellement avec des CNAME en dur dans la zone. Je souhaitais simplement partir sur la même base. Ce qui m'ennuyait c'est que je n'ai pas d'enregistrement A pour ndd.net. Je n'avais pas pensé le faire pointer vers OVH. Tu viens de me donner la solution. Je vais faire un certificat commun aux deux NAS sur le ndd.net.

Puisque le TXT est en principe supprimé, je ferai le même processus pour chaque NAS afin qu'ils soient totalement indépendants l'un de l'autre.

Pour ces fameux enregistrements TXT, je les vois bien actuellement apparaitre dans la zone pour chaque CNAME lorsque je crée un certificat selon la méthode en place, puis disparaître ensuite. Par contre, j'en ai créé 2 avec Wildcard via Docker pour mes propres domaines suivant le tuto d' @Einsteinium l'un sur OVH et l'autre sur Gandi et j'ai toujours les TXT dans leur zone respective.

Pourtant, l'API sur OVH a été créée suivant le tuto avec les bons token à savoir : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/*

Il y a bien le DELETE. Pour Gandi, la chose est plus simple puisqu'il n'y a qu'une seule API et que je ne sais pas ce qu'elle permet, ou pas.

Quel serait le risque si je tente de recréer un nouvel enregistrement TXT alors qu'il en existe un ? Au pire, il corrige la donnée de l'existant non ?

il y a 58 minutes, Einsteinium a dit :

si tu as les log : _clearupdns, Removing DNS records.

J'ai bien ce log et la suite : Removing txt: O94fVTKz4yIdHQRl7xZddjc4C7u3fI3jm5Kcb1DGW-o for domain: _acme-challenge.mondomaine

mais en réalité, l'enregistrement est toujours présent dans la zone.

[Einsteinium]

Mais derrière il met pas une erreur dans le log ? Peu être une erreur de frappe dans l’api au niveau du remove alors ?

Apres c’est pas gênant et tu peux en avoir plusieurs des enregistrements TXT avec la même valeur d’en-tête, exemple la il en faut deux (domaine.tld et *.domaine.tld)

Apres tu es sur que ce n’est pas non plus un ancien enregistrement ? Tu peux delete manuellement sa pose pas de soucis 😉

[Mic13710]

il y a 35 minutes, Einsteinium a dit :

Mais derrière il met pas une erreur dans le log ?

Effectivement, il y a une erreur plus loin, ce qui explique qu'il ne soit pas supprimé. Par contre, difficile d'en comprendre la raison. La lecture de ces logs est un peu difficile.

il y a 36 minutes, Einsteinium a dit :

Apres tu es sur que ce n’est pas non plus un ancien enregistrement ? Tu peux delete manuellement sa pose pas de soucis

Non, c'est bien un enregistrement créé par acme.sh (il a le même texte que dans le log), et je n'avais pas d'enregistrement TXT avant de faire la création via acme.

OK pour le delete manuel, je peux faire ça. Mais je ne vais pas le faire après chaque renouvellement. Il faut donc que je sois sûr que la présence d'un enregistrement TXT n'interdit pas la création (ou sa maj) d'un nouveau texte au prochain renouvellement.

[Einsteinium]

Pour moi ta dû faire une erreur de frappe sur le domaine dans la partie delete de l’api 🙂

[Mic13710]

Tu as probablement raison. Je referai un nouvelle API un peu plus tard.

Pour le moment, je vais me pencher sur les certificats pour les deux domaines dont j'ai parlé dans ce sujet.

[Mic13710]

J'ai suivi les conseils de @.Shad..

Après avoir créé un enregistrement A sur ndd.net pointant vers l'adresse d'OVH et un CNAME *.ndd.net, je viens de mettre en place un certificat qui couvre tout le domaine. Pas de problème pour la création, mais là aussi, le TXT n'est pas supprimé dans la zone.

J'ai suivi l'état de la zone pendant la création et comme je l'avais vu dans les logs précédents, il y a 2 enregistrements TXT qui sont créés pendant le processus. Un à bien été détruit mais l'autre non. Ce qui tendrait à indiquer que le DELETE fonctionne, mais qu'il y a un truc qui ne passe pas.

Je vais m'occuper de l'autre NAS qui est un 214+, ce qui m'oblige à passer par un script dans DSM (pas de Docker sur ce modèle)

[Mic13710]

L'installation en ssh sur le 214 de mon ami s'est faite sans problème. J'ai utilisé la même API que pour son NAS du bureau ce qui m'a évité de devoir faire la double manip indiquée ici : https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api  en rajoutant simplement un export_OVH_CK='consumer key'  avant la création du certificat.

La séquence est donc la suivante :

cd ~
wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
tar xvf master.tar.gz
cd acme.sh-master/
./acme.sh --install --nocron --home /usr/local/share/acme.sh --accountemail "email@gmailcom"
source ~/.profile

cd /usr/local/share/acme.sh
export OVH_AK="your application key"
export OVH_AS="your application secret"
export OVH_CK="your consumer key"
acme.sh --issue --keylength 4096 -d mydomain.com -d *.mydomain.com --dns dns_ovh

export SYNO_Username='Admin_Username'
export SYNO_Password='Admin_Password!123'
export SYNO_Certificate="Le nom de mon certificat dans DSM"
./acme.sh --deploy --home . -d mydomain --deploy-hook synology_dsm

La méthode est donc similaire à celle sous Docker et au final, le fichier de conf est pratiquement identique pour les deux. Par contre, je n'ai pas eu d'enregistrement TXT restant dans la zone après l'opération. A croire que c'est la méthode via docker qui pose problème.

Et pour la mise à jour auto, j'ai mis en place une tâche qui lance le processus une fois par semaine :

/usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/

Sur Docker, cette opération est réalisée tous les jours à 0h00. Je ne sais pas si on peut changer ça pour qu'elle soit lancée qu'une fois par semaine aussi.

[.Shad.]

A en croire la documentation, le réglage par défaut du cronjob est en effet journalier à minuit.
Il utilise simplement le cron du conteneur, il te suffit donc de taper :

docker exec -it <nom_du_conteneur> crontab -e

Ca va sûrement te demander de choisir ton éditeur de texte préféré, puis tu n'auras qu'à modifier le cronjob pour le rendre hebdomadaire, voir ici pour te guider : https://crontab.guru/

[oracle7]

@Mic13710

Bonjour,

Il y a 3 heures, Mic13710 a dit :

Et pour la mise à jour auto, j'ai mis en place une tâche qui lance le processus une fois par semaine :

/usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/

Juste pour attirer ton attention sur le fait que si tu laisses acme.sh procéder au renouvellement automatique de cette façon, tu vas rapidement t'apercevoir qu'il ne fait le "boulot" correctement.

C'est ce que j'explique dans mon TUTO au §10 et qui nous avait conduit @bruno78 et moi même à mettre en place un script spécifique pour finaliser le renouvellement du certificat suite aux retours d'utilisateurs.

Cordialement

oracle7😉

Modifié le 2 novembre 2020 par oracle7

[Mic13710]

Il y a 1 heure, oracle7 a dit :

Juste pour attirer ton attention sur le fait que si tu laisses acme.sh procéder au renouvellement automatique de cette façon, tu vas rapidement t'apercevoir qu'il ne fait le "boulot" correctement.

Pas sûr. C'était vrai avant, et j'avais d'ailleurs fait un script pour pallier les dysfonctionnements que j'avais remarqué lors des renouvellements, mais depuis, il y a eu l'apparition du deploy-hook qui simplifie la tâche et me semble faire correctement le boulot.

A voir si c'est bien le cas lors du prochain renouvellement.

[oracle7]

@Mic13710

Bonjour,

Il y a 12 heures, Mic13710 a dit :

mais depuis, il y a eu l'apparition du deploy-hook qui simplifie la tâche et me semble faire correctement le boulot

Oui le deploy-hook, même s'il fait correctement le "boulot" et je te l'accorde bien volontiers, mais sauf que le deploy-hook n'est fait qu'une seule fois juste après la création du certificat. Ce que j'essaie de te dire, intervient APRÈS, lors du renouvellement, et c'est là que les soucis se produisent/apparaissent. D'ailleurs, le deploy-hook résulte aussi uniquement d'une action manuelle de ta part, en aucun cas il n'est effectué par acme.sh en automatique. De plus, je t'invites à essayer de forcer un renouvellement, tu verras bien le résultat ...

Cordialement

oracle7😉

[Mic13710]

il y a 27 minutes, oracle7 a dit :

D'ailleurs, le deploy-hook résulte aussi uniquement d'une action manuelle de ta part, en aucun cas il n'est effectué par acme.sh en automatique.

Par par acme.sh, mais par le script de renouvellement.

Copie du script au niveau du déploiement :

Le_DeployHook='synology_dsm,'
SAVED_SYNO_Scheme='http'
SAVED_SYNO_Hostname='localhost'
SAVED_SYNO_Port='5000'
SAVED_SYNO_Username='moncompte'
SAVED_SYNO_Password='monmdp'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='Le nom de mon certificat'

La première ligne est assez claire il me semble.

[oracle7]

@Mic13710

Bonjour,

Excuses moi mais je ne comprends pas.

Moi je te parle de la commande :

/usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/

que tu dis avoir placée dans le "cron" pour assurer la mise à jour et manifestement cette commande ne lance pas d'autre script que acme.sh.

Maintenant toi, tu me parles de la commande de déploiement du certificat :

./acme.sh --deploy --home . -d mydomain --deploy-hook synology_dsm

qui elle, est lancée juste après la création du certificat soit au minimum 60j avant que la dite commande de renouvellement ne soit elle-même lancée par le "cron".

J'aurai raté un truc ?

Cordialement

oracle7😉

[.Shad.]

@oracle7

Une fois que tu as exécuté le script et déployé une première fois, le fichier conf de ton nom de domaine contient les informations relayées par @Mic13710.
Le déploiement se fera automatiquement après chaque renouvellement, avec les variables utilisées pour le premier déploiement, simplement en exécutant acme.sh.

[oracle7]

@.Shad.

Bonjour,

OK, j'avais effectivement oublier ce point.

Mais, dans tous les cas malgré cela, ce que j'ai voulu dire précédemment (mal exprimé peut-être) c'est que après le déploiement on constate tout de même deux choses qui nous avaient conduit @bruno78 et moi même à mettre en place un script spécifique pour les corriger aux vues des retours d'utilisateurs (voir mon TUTO au §10 pour le détail) :

 

Citation

1. Même si en apparence le certificat semblait renouvelé dans le « Panneau de configuration / Sécurité / Certificat » avec une nouvelle date d’expiration affichée en vert et qu’il était bien marqué « par défaut », en fait il ne l’était pas complétement. La raison en était que les fichiers « .pem » du nouveau certificat n’avaient en fait, pas été recopiés partout où ils auraient dû l’être et du coup les navigateurs Web utilisaient toujours les anciens fichiers.
2. Par ailleurs, après sa création et/ou son renouvellement, il avait été constaté que le nouveau certificat n’était pas non plus, appliqué et/ou réappliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Il fallait alors reprendre manuellement via le menu « Configurer », toutes les affectations de ce nouveau certificat aux différents services qui l’utilisaient.

C'est juste sur ces deux points que j'ai voulu alerté @Mic13710. C'est uniquement un constat de fait et il lui suffira de vérifier cela dans 3 mois !

Maintenant ce que j'en dit ...

Cordialement

oracle7😉

 

[Einsteinium]

 

Il y a 3 heures, Mic13710 a dit :

Par par acme.sh, mais par le script de renouvellement.

Copie du script au niveau du déploiement :

Le_DeployHook='synology_dsm,'
SAVED_SYNO_Scheme='http'
SAVED_SYNO_Hostname='localhost'
SAVED_SYNO_Port='5000'
SAVED_SYNO_Username='moncompte'
SAVED_SYNO_Password='monmdp'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='Le nom de mon certificat'

La première ligne est assez claire il me semble.

Nan mais après ils ont eu la folie d'utilisé le script à ses débuts, donc forcément le script n'était pas parfait, il y a eu pas loin d'une 30ène de modification sur ce dernier depuis la sortie de février, maintenant au lieu de repartir sur un script parallèle, il suffit de faire remonté le soucis sur github, que les développeur du projet corrige et intègre, le script il soumet en gros le certificat comme nous on le ferrait directement dans l'interface, normalement tu ne devrais pas avoir de problème 😉

[Mic13710]

Lorsqu'il n'y avait pas le hook de déploiement, le script était effectivement loin d'être parfait. Raison pour laquelle je l'ai utilisé et modifié dans le temps pour mes besoins personnels. Il fonctionnait pas mal mais je n'avais pas trouvé de solution autre que de redémarrer le NAS à la fin du script pour que toutes les maj se fassent correctement. Le seul problème c'est que la sauvegarde des snapshots ne redémarrait pas. Il fallait le redémarrer à la mano. La misère.

Le hook à l'air de bien fonctionner, aussi j'espère que cette version est aboutie et permette enfin de faire le renouvellement et le déploiement de manière automatique sans devoir passer par un script additionnel pour corriger les dysfonctionnements. La réponse fin décembre.

[Mic13710]

Le 02/11/2020 à 09:39, .Shad. a dit :

Si je comprends bien, tu as :

sub1.ndd.net     A     IP_publique_NAS1
sub2.ndd.net     A     IP_publique_NAS2
*.sub1.ndd.net.     CNAME     sub1.ndd.net.
*.sub2.ndd.net.     CNAME     sub2.ndd.net.

Ici dans ton cas, tu peux très bien laisser ndd.net pointer en A sur l'hébergement par défaut d'OVH, ce n'est pas important.
Surtout tu ne mets pas d'enregistrement *.ndd.net, car tout ne pointe pas vers la même IP.
Ton certificat sera valide pour tes deux NAS.
Et tu ne changes pas la ligne de commande pour acme.sh

donc :

acme.sh --issue --keylength 4096 -d 'ndd.net' -d '*.ndd.net' --dns dns_ovh

J'ai effectivement suivi ton conseil et ça a résolu mon problème, mais je me suis aperçu au final que le certificat wildcard ne couvrait pas mes domaines *.subx.ndd.net

En fait, le certificat est bien détecté par mon navigateur (Firefox) mais la connexion n'est pas sécurisée car le wildcard ne couvre que le niveau sur lequel il a été créé. J'ai donc revu ma copie pour couvrir le niveau inférieur. La commande appropriée est la suivante :

acme.sh --issue --keylength 4096 -d 'ndd.net' -d 'subx.ndd.net' -d '*.subx.ndd.net' --dns dns_ovh

où subx est soit sub1, soit sub2, soit ...

Je n'ai pas mis de *.ndd.net puisque je n'ai pas d'enregistrement wildcard correspondant dans la zone et hormis sub1 et sub2, je n'ai pas d'autre domaine à ce niveau. Mais j'aurais pu utiliser un *.ndd.net en lieu et place de subx.ndd.net

En conclusion, le certificat wildcard n'est valable que pour le niveau sur lequel il a été créé. Il ne faut pas oublier selon les besoins de rajouter un wildcard par niveau pour couvrir tous les domaines.

[.Shad.]

Hello,
Tu dis en gros qu'avec un certificat wildcard pour *.ndd.net, tu as un avertissement de sécurité pour *.subx.ndd.net ? Ok, c'est possible, je t'avoue que je n'ai jamais eu à faire cela, c'est bon à savoir. 🙂 

Modifié le 12 décembre 2020 par .Shad.

[PiwiLAbruti]

Il y a 9 heures, .Shad. a dit :

Tu dis en gros qu'avec un certificat wildcard pour *.ndd.net, tu as un avertissement de sécurité pour *.subx.ndd.net ?

Je confirme, j'ai le même cas d'utilisation que @Mic13710.

Il faut créer un certificat wildcard par domaine.