Certificati Wildcard con nomi di host brevi?

Sto cercando di generare un certificato con il seguente subjectAltName :

hostname *.hostname hostname.mydomain.local *.hostname.mydomain.local 

Genero il CSR tramite OpenSSL e quindi otterò il certificato da Servizi certificati Microsoft Active Directory. Il certificato funziona OK per i seguenti nomi alternativi:

  • Cifrare / decriptare un file utilizzando openssl tramite uno script autorun
  • ejabberd: impostare Diffie-Hellman (DH) cifre bitsize a> = 2048
  • LDP SSL Port 636 Works - ldaps: // non lo fa
  • configurare CouchDB con Lets Encrypt il certificato SSL
  • Segnetworkingzza perfetta di avanzamento (PFS) per i server di posta
  • lento server apache SSL
  •  hostname hostname.mydomain.local *.hostname.mydomain.local 

    Ma, *.hostname semplicemente non funziona. Test con Curl, ho la seguente output:

     % curl https://m.example/ curl: (51) SSL: certificate subject name '*.example' does not match target host name 'm.example' 

    Se, d'altra parte, aggiungo 'm.example' come sobjectAltName , allora funziona. Così, la wildcard con il nome host abbreviato si rifiuta di lavorare.

    2 Solutions collect form web for “Certificati Wildcard con nomi di host brevi?”

    Esperienza personale

    Un po 'di tempo ho avuto un problema simile.

    Avevo installato un DNS locale per server Windows e Linux con .staging come il TLD. Per salvare la creazione e la firma di certificati per each host virtuale e per evitare di configurare nuovi indirizzi IP (server web non SNI), ho creato una chiave e un certificato per *.staging ma tutti i client che ho provato (incluso curl) hanno riferito solo il nome del sobject certificato *.staging non corrisponde al nome host di destinazione each volta che ho provato a caricare host virtuali sul nostro server Staging utilizzando TLS.

    RFC rilevanti

    Ho passato anni cercando di capire perché il certificato di wildcard che avevo generato per *.staging non funzionasse. Avevo letto tutti i relativi RFC, ma nessuno di loro ha espressamente affermato che un certificato di wildcard era invalido o illegale.

    • Utilizzo di TLS con IMAP, POP3 e ACAP
    • HTTP su TLS
    • Rappresentazione e verifica dell'identity framework; del servizio di applicazioni basata su dominio nell'ambito dell'infrastruttura pubblica di Internet utilizzando i certificati X.509 (PKIX) nel context di TLS (Layer Security)

    Risposte di scambio di stack di protezione

    Alla fine mi sono illuminato dopo aver letto questa risposta eccellente di Security Stack Exchange .

    Ciò che conta è che i client SSL accetteranno come un "certificato valido", vale a dire un certificato che include un nome che "corrisponde" al nome del server previsto (quello incluso nell'URL). Questo è nominalmente specificato nella sezione RFC 2818, sezione 3.1 e consente molti tipi di nomi di caratteri jolly, tra cui cose come " www.*.*c* ", corrispondenti (teoricamente) a qualsiasi nome di server contenente tre componenti, la prima " www " e il terzo contenente alless un " c ".

    Così i venditori di browser hanno fatto i propri schemi e restrizioni. Molto più tardi, è stata pubblicata una nuova RFC (6125, da marzo 2011), con la sezione 6.4.3 dedicata al trattamento di nomi wildcard nei certificati. Quello che RFC 6125 descrive è più in sintonia con la realtà ed è un "standard proposto", quindi c'è alless una certa volontà, a un certo livello, per farlo accadere. Tuttavia, nulla in RFC 6125 obbliga il rigetto di *.com ; tuttavia i browser non lo rifiutano.

    La risposta accettata a Can può essere rilasciato un certificato SSL jolly per un dominio di secondo livello? meritava anche una votazione in su.

    Modifica

    Ho pensato che, oltre a raccontare la frustrazione personale, la mia risposta non aggiunge molto altro che collegarsi alle RFC e le relative risposte in Security Stack Exchange; Pensavo di mettere più sforzo e cercare il codice sorgente corrente utilizzato da Chromium e Firefox.

    Si noti che i commenti nel codice sorgente di Chromium menzionano esplicitamente che i domini di primo livello sconosciuti (come *.intranet ) non sono consentiti.

    Inoltre: non vi è alcun riferimento ad un'opzione configurabile dall'utente che può ignorare questo comportmento.

    Codice sorgente Mozilla

    Dal Mozilla-centrale Mercurio Repository

    Come NSS, richiedere alless due etichette per seguire l'etichetta jolly.

     if (isWildcard) { // If the DNS ID ends with a dot, the last dot signifies an absolute ID. size_t labelCount = (labelLength == 0) ? dotCount : (dotCount + 1); // Like NSS, require at least two labels to follow the wildcard label. // // TODO(bug XXXXXXX): Allow the TrustDomain to control this on a // per-eTLD+1 basis, similar to Chromium. Even then, it might be better to // still enforce that there are at least two labels after the wildcard. if (labelCount < 3) { return false; } // XXX: RFC6125 says that we shouldn't accept wildcards within an IDN // A-Label. The consequence of this is that we effectively discriminate // against users of languages that cannot be encoded with ASCII. if (StartsWithIDNALabel(hostname)) { return false; } // TODO(bug XXXXXXX): Wildcards are not allowed for EV certificates. // Provide an option to indicate whether wildcards should be matched, for // the purpose of helping the application enforce this. } 

    Codice sorgente di cromo

    Dallo Chromium Git Repository

    Non consentire i caratteri jolly per i domini controllati di registro pubblici / ICANN, vale a dire impedire * .com o * .co.uk come nomi presentati validi

    Inoltre, i domini di primo livello sconosciuti (quali domini intranet o nuovi TLD / gTLD non ancora aggiunti al dataset del dominio controllato dal Registro di sistema) sono inoltre impediti implicitamente.

     if (!reference_domain.empty()) { DCHECK(reference_domain.starts_with(".")); // Do not allow wildcards for public/ICANN registry controlled domains - // that is, prevent *.com or *.co.uk as valid presented names, but do not // prevent *.appspot.com (a private registry controlled domain). // In addition, unknown top-level domains (such as 'intranet' domains or // new TLDs/gTLDs not yet added to the registry controlled domain dataset) // are also implicitly prevented. // Because |reference_domain| must contain at least one name component that // is not registry controlled, this ensures that all reference domains // contain at least three domain components when using wildcards. size_t registry_length = registry_controlled_domains::GetRegistryLength( reference_name, registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES, registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES); // Because |reference_name| was already canonicalized, the following // should never happen. CHECK_NE(std::string::npos, registry_length); // Account for the leading dot in |reference_domain|. bool is_registry_controlled = registry_length != 0 && registry_length == (reference_domain.size() - 1); // Additionally, do not attempt wildcard matching for purely numbersc // hostnames. allow_wildcards = !is_registry_controlled && reference_name.find_first_not_of("0123456789.") != std::string::npos; } 

    I commenti in registry_controlled_domain.h sono rilevanti anche:

    Il RegistryControlledDomainService esamina il nome host di un GURL passato ad esso e determina la parte più lunga che è controllata da un registrar. Anche se tecnicamente il dominio di primo livello (TLD) per un hostname è l'ultima parte del nome (come .com o .org), molti domini (come co.uk) funzionano come se fossero TLD, numero di nomi più specifici, essenzialmente non correlati sotto di loro. Ad esempio, .uk è un TLD, ma nessuno può regolare un dominio direttamente sotto .uk; i TLD "efficaci" sono ac.uk, co.uk, e così via. Non vorremmo permettere a nessun sito in * .co.uk di impostare un cookie per l'integer dominio co.uk, quindi è importnte essere in grado di identificare quali domini di livello superiore operano come TLD efficaci e che possono essere registrati.

    Sia i progetti Chromium che Mozilla fondano la loro definizione di un TLD effettivo nell'elenco dei suffissi pubblici come pubblicato da Mozilla.

    I client HTTPS dovrebbero rifiutare di associare i caratteri jolly TLD come *.com o *.net (o anche * ) per motivi di sicurezza: Nessun singolo certificato dovrebbe richiedere un'autorità su un integer TLD.

    Ora come il client dovrebbe scoprire se .example è un TLD (corrispondente *.example vietato) o un breve module (corrispondenza consentita)? Particolarmente considerando che i nuovi TLD si aprono each giorno e qualsiasi elenco TLD statico sarebbe presto scaduto.

    Così i clienti semplicemente rifiutano di abbinare qualsiasi wildcard *.XYZ e si aspettano di vedere alless due punti in una wildcard.

    Si noti che dovrebbero comunque mantenere liste nere di carattere jolly come *.co.uk *.co.jp ecc.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.