Quel nom d'hôte FQDN utiliser pour la demande de signature de certificat SSL - lors de l'utilisation d'un enregistrement CNAME?

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

Ce nom d'hôte DNS dynamique ( https://portal.dlinkddns.com ) se résout en l'adresse IP publique (dynamique) de notre bureau. Au bureau, le routeur est configuré pour transférer le port 443 vers un serveur exécutant un portail Web (Spiceworks) auquel le personnel peut accéder depuis son domicile. Même si l'adresse IP publique du bureau change, le sous-domaine dirigera toujours le personnel vers le portail Web. Tout fonctionne très bien, à part l'erreur (attendue) de certificat SSL que le personnel voit lors de sa première connexion au site.

Je viens d'acheter un certificat SSL et je suis en train de terminer une demande de signature de certificat sur le serveur.

Ce qui m'amène à ma question ...

Lorsque vous remplissez la demande de signature de certificat, pour " Nom commun (par exemple, nom de domaine complet du serveur ou VOTRE nom) ", que dois-je saisir?

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

Toutes suggestions ou idées seraient très appréciées!

Vous utilisez le nom auquel le service est accessible. Donc, si vos clients de 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 accèdent aux deux, obtenez un certificat avec l'un des noms en tant que DN et l'autre en tant que subjectAltName, afin qu'il puisse être utilisé pour les deux.

Si je lis correctement entre les lignes de votre question, tout ce qui sera accessible dans un navigateur est https://portal.company.com , alors dans votre cas: obtenez un certificat pour ce nom.

Si vous avez le domaine company.com (par exemple) et que vous souhaitez que le nom commun du certificat "fonctionne tout simplement", envisagez d'utiliser un nom commun basé sur des caractères génériques comme celui-ci: *.company.com

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

Remarque: Je l'ai utilisé uniquement dans les certificats auto-signés, créés avec la commande openssl, mais cela peut également fonctionner pour les "vrais" certificats; Je ne vois pas pourquoi ils ne le feraient pas. (Mais j'ai entendu dire que les certificats génériques pouvaient être plus chers que les certificats non génériques, lors de leur achat.)

Il est dommage que la commande openssl ne donne pas ces informations à titre indicatif lorsqu'elle demande le nom commun. Lors de la signature automatique de mes certificats SSL pour les serveurs de test, j'utilise régulièrement un nom commun au format "* .company.com".