L'IP SubjectAltName critico: x.x.x.x su un limite di certificato client SSL da cui è possibile utilizzare il certificato?

3

Ho l'obbligo di limitare i certificati SSL per IP sorgente.

L'impostazione di un SubjectAltName critico potrebbe limitare questo problema (la validazione lato server è eseguita da OpenSSL via nginx)? In caso contrario, come potrebbe essere implementato?

    
posta Kimvais 14.01.2014 - 09:15
fonte

2 risposte

7

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.

    
risposta data 14.01.2014 - 11:53
fonte
3

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.

    
risposta data 14.01.2014 - 15:45
fonte

Leggi altre domande sui tag