Mentre lavoravo su uno scenario, ho ricevuto il messaggio di errore "I certificati del server non corrispondono all'URL".
È necessario che il certificato fornito dal sito Web abbia il suo URL? È necessario che il certificato abbia il nome completo dell'URL o funzionerà anche se utilizzo una parte dell'URL?
Innanzitutto, non è un URL, è un nome host o un nome di dominio. Il nome host è una parte dell'URL. http://security.stackexchange.com/questions/92838/is-it-neccessary-the-website-certificate-must-have-site-url è un URL e il nome host è security.stackexchange.com .
Successivamente, sì, almeno un nome host nel certificato deve corrispondere al nome host esatto utilizzato per accedere al sito. Puoi ottenere i certificati jolly, ad es. * .example.com, che corrisponde a < qualsiasi cosa > .example.com (ma non a < qualsiasi cosa >. < qualsiasi >. esempio.com o esempio.com).
Sì, il nome host sul certificato deve corrispondere alla parte del nome host dell'URL da cui viene richiesto il certificato. Questo è un requisito in quanto vi è l'aspettativa che SSL non solo protegga la comunicazione (crittografia) ma assicuri anche che l'utente si colleghi al server appropriato (autenticazione). Senza tale requisito sarebbe banale spoofare gli utenti con un attacco MITM. L'utente sfoglia il link , l'hacker MITM non può creare un certificato firmato dalla CA valido per esempio.com, quindi usa solo un certificato valido. L'utente vede che l'URL è link ed è protetto SSL per cui deve essere sicuro, giusto? No, è connesso al server degli hacker. Quindi il browser avviserà l'utente. Ehi hai provato ad andare al link , il vero esempio.com avrebbe fornito un certificato per example.com ma ho ottenuto qualcosa di diverso, quindi molto probabilmente sei sotto attacco in questo momento.
Uno scenario comune che porta ad errori è richiedere un certificato con un nome host di www. * come www.example.com. Tutto va bene se l'utente tenta di accedere al link , ma se decidi di aderire al 21 ° secolo e gestire il traffico a link l'utente riceverà un errore (non è possibile reindirizzare anche senza un errore diverso). L'utente sta provando ad andare su example.com ma sta ottenendo un certificato per un nome host diverso (www.example.com).
È pratica (semi) standard per la CA includere www. * come alt nome per cert quando il nome host richiesto è un dominio radice (nessun sottodominio). Una richiesta per un certificato con un nome host di example.com funzionerà con entrambi i link e link ma se una richiesta di un certificato per www.example.com funzionerà solo con link .
Potresti ricevere un secondo certificato emesso per gestire il traffico link e utilizzare il cert esistente www www per link ma è un po 'inutile in quanto il nuovo certificato può gestire entrambi i nomi degli host. Si consiglia di verificare se la CA rilascerà un certificato con il nome host di root invece di www gratuitamente. Dubito che lo faranno ma potrebbero soprattutto se è un certificato più costoso.
Sembra che alcune CA (vedere i commenti) ora facciano l'opposto e per un certificato richiesto su www.example.com aggiungere example.com come nome alt. Niente può essere semplice, immagino. Verificare con la CA e i dettagli della cert. Per evitare gli avvertimenti del browser, il nome host dell'URL utilizzato deve essere elencato nel certificato come nome host o Nome alternativo oggetto.
Ho trovato la risposta da (RFC2818) link Secondo rfc Se è presente un'estensione subjectAltName di tipo dNSName, DEVE essere utilizzata come identità. In caso contrario, DEVE essere utilizzato il campo Nome comune (più specifico) nel campo Oggetto del certificato. Sebbene l'uso del nome comune sia una pratica esistente, è deprecato e le autorità di certificazione sono invece incoraggiate a utilizzare dNSName.
Possiamo anche usare Ip, e come @mike ha detto che può essere hostname con operatore jolly.
Mike Scott ha pubblicato un'ottima risposta. Ma potrebbe valere la pena notare perché è importante. A livello tecnico i tuoi dati saranno comunque crittografati. Tuttavia, è possibile che gli utenti vengano allontanati perché non possono fidarsi del certificato poiché molti browser li avvertiranno dell'errore e in genere li fanno compiere ulteriori passaggi attraverso i messaggi di avviso. I messaggi sono fatti per spaventare apposta nel tentativo di allontanare anche gli utenti non tecnici. In alcuni casi un browser potrebbe non consentire loro di visitare il tuo sito. Nel complesso non farlo. Il tuo sito di produzione non dovrebbe mai tagliare gli angoli quando si tratta di sicurezza.
Leggi altre domande sui tag public-key-infrastructure tls