3 votes

Le certificat Wildcard provoque un avertissement sur Google Chrome uniquement

J'ai un entreprise.sv et j'ai récemment acheté un certificat RapidSSL wildcard, je l'ai installé et testé avec de nombreux navigateurs (Firefox, Chromium, Chrome, IE) et outils de vérification SSL, il a fonctionné correctement sur chacun d'entre eux sauf sur Google Chrome sous Windows, Linux et Android.

Chaque fois que j'accède au site Web via Google Chrome, un message d'avertissement s'affiche, indiquant que j'ai essayé d'accéder au site. www.company.sv o quoi que ce soit.entreprise.sv mais le serveur s'identifie comme **.company.sv*. Si je continue malgré l'avertissement et que je clique sur le verrou rouge, il m'indique que je suis connecté à un serveur qui n'est valable qu'à l'intérieur de mon réseau et qui ne peut pas être validé par une entité de certification externe.

J'ai contacté le service d'assistance du revendeur de certificats mais ils n'ont pas pu me donner une réponse claire sur l'origine du problème. Je me demande si cela n'a pas quelque chose à voir avec le fait que le TLD soit .sv . J'ai également vérifié le code source de Chromium mais cela semble inutile puisque le certificat fonctionne parfaitement sur Chromium.

Il est peut-être utile de préciser que j'utilise NGINX sur un serveur Ubuntu 12.04 et que j'ai testé un certificat gratuit de Comodo pour un seul domaine avant d'acheter le certificat de type "wildcard".

1 votes

Il peut être utile d'inclure le domaine, si vous le pouvez, afin que les personnes qui répondent puissent interroger directement le serveur.

0 votes

8 ans après le premier message, j'ai le même problème... J'ai un certificat de type wildcard (*.myorg.com) installé sur un serveur interne (intranet). Chrome et Edge signalent que ce certificat est invalide alors qu'il est valide. Quelle a été la résolution finale de ce problème ? Cela fonctionnerait-il encore maintenant ?

1voto

Michael Hampton Points 232226

Il semble que vous ayez oublié d'installer le paquet de certificats intermédiaires sur votre serveur web. Visitez le site Web du fournisseur de certificats pour télécharger le paquet intermédiaire.

Pour nginx, il doit être concaténé avec votre certificat et placé dans le répertoire ssl_certificate par exemple :

# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt

Et dans votre configuration nginx :

ssl_certificate /etc/path/to/company.sv.chained.crt

0 votes

Les certificats intermédiaires sont corrects, c'est l'une des premières suggestions que j'ai reçues du support technique. J'ai enquêté un peu plus et apparemment il y a un bug dans Google Chrome puisque cela fonctionne très bien dans la version bêta (32.0) et dev/Canary (33.0).

0 votes

Y a-t-il un ordre spécifique dans le certificat enchaîné ?

1voto

Stuart Points 101

Je soupçonne que vous avez le nom du site dans le champ Subject CN=, il doit être dans le champ subject alternate name pour que Chrome l'accepte. Si vous affichez le certificat dans le navigateur, ou avec openssl x509 -in certificate-file -text

Voir :

cet article de blog

Ces exigences de base obligent les autorités de certification à toujours inclure au moins un nom alternatif de sujet dans les certificats SSL qu'elles délivrent, ce qui signifie qu'aujourd'hui, une application n'a pas besoin de rechercher à la fois le nom commun et le nom alternatif de sujet ; elle doit seulement vérifier ce dernier.

Actuellement, la plupart des autorités de certification incluent le premier nom DNS du nom alternatif de l'objet dans le champ du nom commun, mais cela est fait principalement pour des raisons d'héritage et cela cessera à un moment donné dans un avenir pas si lointain.

cette discussion

Les certificats ont deux façons d'exprimer le domaine/IP auquel ils sont liés - une qui est non structurée et ambiguë (commonName), et une qui est bien définie (subjectAltName). En l'absence de subjectAltNames, Chrome se contente actuellement de comparer le domaine au commonName, s'il est présent.

La présente proposition vise à supprimer cette solution de repli ; en fait, elle exige un subjectAltName. Idéalement, nous ferions cela pour tous les certificats (de confiance publique et privée), mais s'il y a des préoccupations concernant le risque de compatibilité, nous pouvons le restreindre aux certificats de confiance publique.

0 votes

Vraisemblablement votre suggestion est d'omettre le Subject champ ?

0 votes

Non, vous avez besoin du champ "subject", c'est juste que celui-ci n'est plus utilisé pour l'URL du site (dans le champ CN=) et que tous ces éléments doivent être dans le champ "alternate name".

0 votes

Omettez donc le Subject: CN = domain

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X