[Résolu] Certificat SSL différent pour un sous domaine
... / [Résolu] Certificat SSL d...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

[Résolu] Certificat SSL différent pour un sous domaine

Par
JoseR5
Créé le 2021-07-15 15:58:15 (edited on 2024-09-04 13:18:40) dans Erreur connexion SSL

Bonjour,

j'ai un VPS OVH avec YUNOHOST + nom de domaine.
Mon certificat SSL est chez Let's Encrypt par l'application YUNOHOST.org .

Hors des applications YUNOHOST, j'ai un hébergement chez https://gitbook.com et il propose de pointer mon espace de documents vers un sous-domaine "docs.mudomain.tld. Super !

Gitbook fournit ce code : `CNAME hosting.gitbook.io` à mettre dans les dns, Encore mieux !

Je l'ai installé et OVH indique que le nom de domaine étant déjà protégé par un certificat existant, il n'est pas possible d'ajouter un certificat pour ce sous-domaine :'-(.

Gitbooks est chez Digicert.

Existe-t-il une solution :) Merci d'avance.

Amicalement, José

-----
Résolut par @janus57 : mettre tous les CAA sur le domaine principal (et pas sur le sous-domaine comme j'avais fait !)


17 réponses ( Latest reply on 2021-07-31 11:18:50 Par
JoseR5
)


YUNOHOST


Je vous conseille plutôt les forums Ynuohost, ils sont très réactifs aussi bien en français qu'en anglais.
Une chose est certaine: ce n'est pas à OVH de s'occuper du certificat.

Merci du retour.
Oui, bien sûr, ce n'est un pb venant d'OVH.

Je pensais trouvé plus de personnes avec des **compétences en DNS et SSL** ici que sur le forum de YNH :)
Je vais posé la question :)
Merci, josé


compétences en DNS et SSL ici que sur le forum de YNH


YNH est particulier avec DNS et joue des tours de cochon ... si tu déclares ton yunohost comme étant example.com car il doit réceptionner les mails de @example.com, le serveur DNS (dnsmasq) a tendance à diriger *.example.com vers l'adresse locale, même quand ce n'est pas vrai...
Pour SSL, YNH gère ça nickel et sans difficulté.


Pour SSL, YNH gère ça nickel et sans difficulté.


Oui mais avec un seul certificat, Let's Encrypt.

Je crois que le problème vient du sous-domaine "*" (Certificat Wildcard).

J'avais posé la question ici : https://forum.yunohost.org/t/resolu-the-certificat-wildcard-nomdomaine-tld-with-yunohost/15795

Encore merci.

Bonjour, ça marche

J'ai eu un retour du forum YNH où il m'a été conseillé :
- soit de retirer le CAA Let's Encrypt, c'est que j'ai fait et cela marche
- Soit ajouter un nouveau CAA Digicert, j'ai tenté mais j'ai eu un message d'erreur :
>Le sous-domaine est déjà utilisé par un enregistrement CNAME. Un enregistrement **CNAME n’est pas autorisé à coexister avec d’autres champs sur le même sous-domaine**.

À tout hasard, je pose la question, est-il possible d'avoir deux CAA ?
Dans mon cas,
- Let's encrypt pour le nom de domaine (jreservices.fr)
- Digicert pour un des sous-domaines (GitBook) docs.jreservices.fr

Merci de votre temps.

Bonjour,


À tout hasard, je pose la question, est-il possible d'avoir deux CAA ?

oui car 1 entrée CAA == 1 autorité de certification

Après vu le message d'erreur vous avez mal déclaré le CAA.

Cordialement, janus57

Je ne vois pas trop où il y a une erreur

je choisis CAA.

### Écran 2/3


### Écran 2/3


Et c'est le seul CAA pour l'instant :)

Alors, c'est vrai qu'il y a ce CNAME, demandé par GitBook :
`docs.jreservices.fr. 0 CNAME hosting.gitbook.io.`

Merci d'avance d'un retour :).
Amicalement, José

Bonjour,

sauf que c'est (de mémoire) pas possible d'avoir un CNAME + CAA.

Du coup il faut déclarer les deux CAA sur la racine.

De plus je ne sais pas pourquoi vous avez l'indicateur à 128.

Cordialement, janus57


Merci de ce retour rapide.

Alors j'applique les recommandations de YUNOHOST.

Pour mon certificat, il recommande (voir la dernière ligne) :
```
; Basic ipv4/ipv6 records
@ 3600 IN A 51.xx.xx.xxx
@ 3600 IN AAAA 2001:xxxx::6f4c

; XMPP
_xmpp-client._tcp 3600 IN SRV 0 5 5222 jreservices.fr.
_xmpp-server._tcp 3600 IN SRV 0 5 5269 jreservices.fr.
muc 3600 IN CNAME @
pubsub 3600 IN CNAME @
vjud 3600 IN CNAME @
xmpp-upload 3600 IN CNAME @

; Mail
@ 3600 IN MX 10 jreservices.fr.
@ 3600 IN TXT "v=spf1 a mx -all"
mail._domainkey 3600 IN TXT "v=DKIM1; h=sha256; k=rsa; p=MIGfxxxxAB"
_dmarc 3600 IN TXT "v=DMARC1; p=none"

; Extra
* 3600 IN A 51.xx.xx.xxx
* 3600 IN AAAA AAAA 2001:xxxx::6f4c
@ 3600 IN CAA 128 issue "letsencrypt.org"
```

En complément de la configuration de base : https://yunohost.org/en/dns_config

Cette incompatibilité m'apparaît étrange.
Je n'y connais rien en DNS mais le CNAME (nom générique) et le CAA (certificat) me semblait complètement différent.

Merci d'un retour.

Bonjour,

je conseillerais de laisser à 0 à la place de 128.

Cordialement, janus57

Non, rien à faire. Et pourtant, je commence par le CAA Digicert



Par contre, je peux faire un CAA Let's encrypt sur le nom de domaine lui-même (celui du serveur YNH où j'ai déclaré le certificat Let's Encrypt.

Je comprends que l'incompatibilité vient du CNAME - CAA

Amicalement, José

Bonjour,

oui mais non comme dit plus haut faut le mettre à la racine c'est pas possible de déclarer un CAA si il y a déjà un CNAME de déclaré pour la même entrée.

Cordialement, janus57

Tu me dis qu'il n'est pas possible d'avoir un certificat pour le nom de domaine déclaré par CAA

Et des certificats différents pour des noms de sous-domaines pour ce même nom de domaine déclarés avec des CAA différents.

J'ai enlevé tous les CAA et tout a marché :).

Là, j'ai remis le certificat CAA au nom de domaine (pour ne plus avoir d'erreur sur l'autodiagnostic YNH)

Merci de tes retours. Je vais voir lors du renouvellement du certificat :)

Bonjour,

non je disais qu'il fallait mettre tout les CAA à la racine du domaine.

Car avec un CNAME l'autorité de certification va allez voir si il y a une entrée CAA sur la cible du CNAME (donc ici hosting.gitbook.io) et si il n'y en a pas elle va retourner voir la racine du domaine ou il n'y avais que let's encrypt de défini donc ==> échec

Donc tout mettre à la racine et autoriser les wildcard suffit à ce que tout rentre dans l'ordre.

Cordialement, janus57

Ah génial.

Oui, cela marche !
Et j'ai les deux CAA !

C'est bien moi, pourquoi faire simple quand on peux faire compliquer !

Donc tous les CAA sur sur le nom de domaine principale.

Merci, amicalement, José

(Je ne crois pas que l'on puisse dire sur ce forum que c'est ton poste qui a résolu le pb :)

Voir le fil sur YNH : https://forum.yunohost.org/t/solved-sous-domaine-externe-a-ynh-pour-pointer-sur-une-doc-gitbook/16694

Bonjour,

je vais faire mon reloue mais l'indicateur à 128 reste une mauvaise idée.

128 == flags=1 ==> bloque la validation si le tag est inconnu par l’autorité de certification
0 == flags=0 ==> standard

Cf : https://datatracker.ietf.org/doc/html/rfc8659 + https://datatracker.ietf.org/doc/html/rfc6844

Cordialement, janus57

Bonjour, tu fais bien d'insisté.
J'ai remis 128 car c'est la recommandation YNH :)

Je vais partager ton commentaire avec eux. Cela fait des années qu'ils recommandent 128 :)
https://forum.yunohost.org/t/la-recommandation-ynh-des-caa-a-128-au-lieu-de-0/16723

Si il y a un pb, je peux le retirer rapidement :)

Encore merci, José