Quale nome host FQDN da utilizzare per la richiesta di firma del certificato SSL quando si utilizza un record CNAME?

Abbiamo un sottodominio ( https://portal.company.com ) che è l'alias per un nome host diverso (definito in un record CNAME).

Questo nome host DNS dinamico ( https://portal.dlinkddns.com ) si risolve nell'indirizzo IP pubblico (dinamico) del nostro ufficio. In ufficio, il router è configurato per inoltrare la porta 443 a un server che esegue un portale Web (Spiceworks) a cui lo staff può accedere da casa. Anche se l'indirizzo IP pubblico dell'ufficio cambia, il sottodominio indirizzerà comunque il personale al portale Web. Tutto funziona alla grande, a parte il (previsto) errore del certificato SSL che lo staff vede quando si connettono per la prima volta al sito.

Ho appena acquistato un certificato SSL e ora sto completando una richiesta di firma del certificato sul server.

Il che mi porta alla mia domanda ...

Quando si completa la richiesta di firma del certificato, per " Nome comune (ad es. FQDN del server o nome utente) ", cosa devo inserire?

Devo inserire il nome canonico ( https://portal.dlinkddns.com ) o l'alias ( https://portal.company.com )? L'FQDN del server stesso è "servername.companyname.local" - quindi non posso usarlo.

Eventuali suggerimenti o idee sarebbero molto apprezzati!

Si utilizza il nome a cui si accede al servizio. Pertanto, se i client del portale visitano https://portal.dlinkddns.com , utilizzare portal.dlinkddns.com. E se visitano https://portal.company.com , utilizzare portal.company.com.

Se i tuoi clienti accederanno ad entrambi, ottieni un certificato con uno dei nomi come DN e l'altro come subjectAltName, in modo che possa essere utilizzato per entrambi.

Se sto leggendo correttamente tra le righe della tua domanda, tutto ciò a cui si accederà in un browser è https://portal.company.com , quindi nel tuo caso: ottenere un certificato per quel nome.

Se si dispone del dominio company.com (ad esempio) e si desidera che il nome comune del certificato "funzioni", prendere in considerazione l'utilizzo di un nome comune basato su caratteri jolly come questo: *.company.com

Quindi il certificato SSL dovrebbe funzionare per https://company.com e https://www.company.com e per qualsiasi sottodominio che si sceglie di utilizzare.

Nota: l'ho usato solo in certificati autofirmati, creati con il comando openssl, ma potrebbe funzionare anche con certificati "reali"; Non vedo un motivo per cui non lo farebbero. (Ma ho sentito che i certificati con caratteri jolly potrebbero essere più costosi dei certificati non con caratteri jolly, se acquistati.)

È un peccato che il comando openssl non dia queste informazioni come suggerimento, quando chiede il nome comune. Quando firmo automaticamente i miei certificati SSL per i server di test, utilizzo abitualmente un nome comune nel formato "* .company.com".