URI nell'estensione X.509 subjAltName

Question

URI nell'estensione X.509 subjAltName

#1 da (4 voti)

2

L'estensione subjAltTag per i certificati X.509 può contenere nomi di dominio, indirizzi email, URI, ecc. Stavo giocando con un X.509 il cui subjAltTag aveva solo un URI in esso non sembra funzionare. Ecco uno screenshot:

L'URI nella barra degli indirizzi - nella parte superiore - è lo stesso URI nel certificato. Ho aggiornato il file hosts per indicare www.google.com a localhost. Cert è praticamente cert di google.com rassegnato.

La mia domanda è ... perché non funziona? I browser supportano solo i nomi di dominio?

Il certificato X.509 e la corrispondente chiave privata RSA sono allegati:

Ecco gli errori specifici che Firefox mi sta dando:

The certificate is not trusted because it is self-signed.
The certificate is not valid for any server names.

Qualche idea?

public-key-infrastructure tls certificates x.509

posta compcert 21.04.2012 - 18:50

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure tls certificates x.509

In Metasploit, come usare un exe personalizzato come payload? Alla ricerca di una presentazione sulla sicurezza delle informazioni per i dipendenti aziendali

score 4 · Accepted Answer

Quando si effettua una connessione HTTPS, le regole utilizzate per verificare l'identità del server sono ancora quelle fornite in RFC 2818 (Sezione 3.1) :

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

[...]

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.

Nel certificato, non è presente un'estensione SAN (Other Alternative Name) di tipo DNS ( dNSName ). Quindi, ricade sul nome comune del DN dell'oggetto.

Una specifica più recente ( RFC 6125 ) armonizza la procedura di verifica del nome host su altri protocolli. Tuttavia, non è ancora ampiamente implementato.

Permette l'uso di URI e dice questo (tra le altre cose):

[...] Therefore this document discusses Uniform Resource Identifiers [URI] only as a way to communicate a DNS domain name (via the URI "host" component or its equivalent), not as a way to communicate other aspects of a service such as a specific resource (via the URI "path" component) or parameters (via the URI "query" component).

Essenzialmente, solo lo schema e il nome host sono realmente usati da quell'URI. Ciò significa che è solo più specifico di una voce SAN DNS limitando l'utilizzo a un determinato protocollo (nemmeno la porta, per quanto ne so, da una lettura veloce).

Questa specifica è stata finalizzata solo un anno fa, ma non è così lungo. Non è chiaro quanto sarà ampiamente adottato. Per chiarire e armonizzare le pratiche esistenti, vale sicuramente la pena, ma suppongo che le CA e gli implementatori dovrebbero conoscerlo meglio e trovare una richiesta per emettere certificati con SAN URI, poiché non si associa alle specifiche precedentemente utilizzate (RFC 2818). Immagino che ci sarebbe poca richiesta da parte dei fornitori di servizi, dal momento che pochi client lo supportano comunque.

Molti browser non implementano completamente RFC 2818 così com'è (essendo più indulgente sugli indirizzi IP nel CN del nome soggetto, ad esempio, senza SAN).

(Come nota a margine, dal punto di vista del certificato client, potresti essere interessato al WebID progetto , che esplora altri modi oltre a PKIX di verificare un certificato client e utilizzare gli URI nella SAN.