Quel nom d'hôte FQDN à utiliser pour la request de signature de certificate SSL – lors de l'utilisation d'un logging CNAME?

Nous avons un sous-domaine ( https://portal.company.com ) qui est l'alias pour un nom d'hôte différent (défini dans un logging CNAME).

Ce nom d'hôte DNS dynamic ( https://portal.dlinkddns.com ) résout l'adresse IP publique (dynamic) de notre bureau. Au bureau, le routeur est configuré pour transmettre le port 443 à un server exécutant un portail Web (Spiceworks) que le personnel peut accéder depuis son domicile. Même si l'adresse IP publique du bureau change, le sous-domaine continuera de diriger le personnel vers le portail. Tout fonctionne très bien, à l'exception des erreurs de certificate SSL (attendues), le personnel voit quand il se connecte au site.

Je viens d'acheter un certificate SSL et je suis maintenant en train de remplir une request de signature de certificate sur le server.

Ce qui m'amène à ma question …

Lorsque vous remplissez la request de signature de certificate, pour " Nom commun (p. Ex. FQDN du server ou VOTRE nom) ", que dois-je entrer?

Devrais-je entrer le nom canonique ( https://portal.dlinkddns.com ) ou l'alias ( https://portal.company.com )? Le FQDN du server lui-même est "servername.companyname.local" – donc je ne peux pas utiliser cela.

Toute suggestion ou idée serait très appréciée!

2 Solutions collect form web for “Quel nom d'hôte FQDN à utiliser pour la request de signature de certificate SSL – lors de l'utilisation d'un logging CNAME?”

Vous utilisez le nom auquel le service est accessible. Donc, si vos clients du portail visitent https://portal.dlinkddns.com , utilisez portal.dlinkddns.com. Et s'ils visitent https://portal.company.com , utilisez portal.company.com.

Si vos clients ont access aux deux, obtenez un certificate avec l'un des noms sous le nom DN et l'autre comme subjectAltName, de sorte qu'il peut être utilisé pour les deux.

Si je lis correctement entre les lignes de votre question, tout ce qui sera consulté dans un browser est https://portal.company.com , donc dans votre cas: obtenez un certificate pour ce nom.

Si vous avez le domaine company.com (par exemple) et que vous souhaitez que le nom commun du certificate «fonctionne juste», envisagez d'utiliser un nom commun de caractère générique comme celui-ci: *.company.com

Ensuite, le certificate SSL devrait fonctionner pour https://company.com et https://www.company.com et quels que soient les sous-domaines que vous choisissez d'utiliser.

Remarque: je l'ai utilisé uniquement dans les certificates auto-signés, créés avec la command openssl, mais cela pourrait également fonctionner pour les certificates "réels"; Je ne vois pas une raison pour laquelle ils ne le feraient pas. (Mais j'ai entendu dire que les certificates generics pourraient être plus chers que les certificates non-generics, lorsqu'ils sont achetés.)

Il est dommage que la command openssl ne donne pas cette information comme un indice, lorsqu'il request le nom commun. Lors de la signature automatique de mes certificates SSL pour les servers de test, j'utilise habituellement un nom commun dans le format "* .company.com".

  • L'URL SSL donne un 404
  • Proxy direct Linux pour l'authentification client
  • Avoir de nombreux sous-domaines avec SSL - les meilleures pratiques?
  • Certificat public ou de domaine WSUS
  • Nginx vérifie les certs clients uniquement sur un location particulier
  • Jetty s'écrase après avoir chiffré l'import de certificate
  • Multiple SSL Certificate sur Apache
  • Quelle est la force maximale d'un certificate SSL générique
  • Devrais-je m'inquiéter des pannes lors du routing automatique des certificates token ADFS?
  • nouvel user et problèmes avec la configuration de la key ssh (pub vs pem files)
  • le wildcard ssl est-il instable?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.