No. SubjectAltName fornisce nomi alternativi, quindi significa che il certificato è valido per il nome Subject e anche per qualsiasi nome elencato in SubjectAltName . Non crea un requisito aggiuntivo da soddisfare, ma fornisce un requisito alternativo da soddisfare.
Quindi un certificato lato server con nomi alternativi "www.example.com" e "192.168.1.5" sarebbe considerato valido per https://192.168.1.5/ OR https://www.example.com/ . Entrambi i criteri non devono essere soddisfatti, solo uno di essi.
Tuttavia, tale certificato non corrisponde all'URL https://test.example.com/ anche se l'indirizzo IP di test.example.com era in effetti 192.168.1.5 . Viene controllato solo il nome visualizzato nell'URL.
Per limitare l'uso di un certificato a un particolare IP, è necessario implementare le proprie restrizioni, probabilmente a livello di applicazione. Cioè dovrai scrivere un codice che controlli l'IP del client e il certificato e convalida che le regole sono rispettate, restituendo un codice di stato HTTP adatto, in caso contrario.
Quello che fai con un certificato client dipende interamente dal server. Non esiste una regola standard. È possibile decidere, sul lato server, che un determinato certificato client è accettabile solo se la connessione proviene da uno specifico indirizzo IP; questo dipende da cosa supporta il codice server, non dal contenuto del certificato.
Per il certificato server , quello è validato dai client, e i client seguono (più o meno) le regole date in RFC 2818 . Ciò significa che i client si aspettano che il nome server (come appare nell'URL di destinazione) sia presente nel certificato del server, nella sua estensione Subject Alt Name (se non c'è tale estensione, i client sembreranno nel Nome comune nel DN soggetto). Solo i nomi sono abbinati (di tipo dNSName ); sebbene l'estensione SAN possa contenere indirizzi IP (di tipo iPAddress ), tali indirizzi non sono considerati dai client HTTPS.
(Esiste un'eccezione teorica: se l'URL non contiene un nome ma una rappresentazione di un indirizzo IP, ad esempio in "decimal-punteggiato", allora quell'indirizzo IP deve corrispondere a un iPAddress nome nell'estensione SAN. è consentita una corrispondenza esatta, non esiste una corrispondenza simile a un carattere jolly. I nomi dNSName vengono quindi ignorati Questa possibilità è specificata in RFC 2818 ma non è chiaro se i browser esistenti lo implementano, è noto che i browser non seguono esattamente le regole, in particolare implementano solo un sottoinsieme limitato di caratteri jolly. In ogni caso, non l'ho mai visto usato in natura, e non sarebbe flessibile, dal momento che gli indirizzi IP sono soggetti a modifiche, motivo per cui il DNS è stato inventato in primo luogo.)
Non importa se l'estensione è critica o meno. Quando un'estensione è critica, qualsiasi sistema che elabora il certificato deve rifiutarlo del tutto se non capisce l'estensione. Ma la semantica di estensione non è alterata dalla criticità. Poiché tutti i client HTTPS ragionevoli (e i server, quando richiedono i certificati client) supportano l'estensione SAN, rendendo assolutamente nulla le modifiche critiche.
Leggi altre domande sui tag openssl certificates