Czy certyfikat wildcard chroni domenę główną?

29 Nov 2019

certificates  ssl  tls  wildcard 

Share on:

Certyfikaty typu wildcard są certyfikatami klucza publicznego wydawanymi na podstawie „nieznanych potomków” poddomeny i pozwalają chronić dowolną liczbę subdomen w domenie głównej. Większość certyfikatów wieloznacznych wydawanych jest dla domen 3-częściowych, np. *.a.com, ale można je także spotkać w przypadku domen 4-częściowych, np. *.b.a.com.

Odpowiedź na zadane w tytule pytanie nie jest wcale taka oczywista. Przeanalizujmy ten problem na przykładzie domeny yoursite.com oraz certyfikatu wildcard wystawionego tylko dla *.yoursite.com.

Co mówią standardy? #

Zacznijmy od RFC 1034 - 4.3.3. Wildcards [IETF], czyli najstarszego z omawianych dokumentów, który w sposób dwuznaczny określa, w jaki sposób należy interpretować nazwy wieloznaczne, jednak, co należy podkreślić, w kontekście nazw domenowych, a nie w kontekście certyfikatów.

Mówi on, że w systemie DNS rekord wieloznaczny powinien zawierać tylko jedną etykietę gwiazdki, czyli taki element nazwy domenowej, który jest oddzielony kropkami (obecnie traktowany jako skrajnie lewy lub najmniej znaczący). To samo RFC podaje drugą interpretację, gdzie rekord wieloznaczny może pasować do jednej lub większej ilości etykiet. Jednak jeśli na etykiecie znajduje się coś innego niż gwiazdka, nie jest to symbol wieloznaczny. Druga istotna sprawa jest taka, że symbol wieloznaczny nie odnosi się do domeny głównej (co jest pierwszą odpowiedzią na nasze pytanie).

The owner name of the wildcard RRs is of the form "*.anydomain", where 'anydomain' is any domain name. 'anydomain' should not contain other * labels, and should be in the authoritative data of the zone. The wildcards potentially apply to descendants of 'anydomain', but not to 'anydomain' itself. Another way to look at this is that the "*" label always matches at least one whole label and sometimes more, but always whole labels.

Na przykład serwer BIND po ustawienie symbolu * dla domeny yoursite.com zwróci pozytywną odpowiedź co oznacza pobranie wszystkich nazw z tej domeny, czyli w tej implementacji symbol wieloznaczny będzie pasował do jednej lub więcej etykiet DNS:

Podobne zachowanie prezentuje z kolei serwer NGINX, czyli nazwa *.yoursite.com złapie www.yoursite.com, ale także www.sub.yoursite.com. Natomiast zapisy nazw domen takie jak www.*.yoursite.com czy w*.yoursite.com są nieprawidłowe i w celu ich obsługi należy użyć wyrażeń regularnych.

Kolejnym ze starszych dokumentów jest RFC 2459 - Server Identity Check [IETF], które stwierdza:

A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.

Inna z istotnych odpowiedzi znajduje się w RFC 2818 - Server Identity [IETF]:

Matching is performed using the matching rules specified by RFC 2459. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Powyższe dokumenty stwierdzają, że symbole wieloznaczne są dobre tylko dla poziomu niżej i działają tylko na pierwszym poziomie subdomeny.

Zgłębiając jednak temat, spotkałem się ze stwierdzeniami, że użycie symboli wieloznacznych i nazw takich jak *.*.yoursite.com, foo.*.bar.*.yoursite.com czy nawet *.*.* jest dopuszczalne i wywodzi się wprost z RFC (czego w pewnym sensie potwierdzenie zostało opisane w dalszej części artykułu) oraz jest zależne od przeglądarek. Nie zdziwiłbym się gdyby faktycznie tak było, ponieważ jak to zwykle bywa, między teorią a praktyką mogą występować pewne różnice. W przypadku przeglądarek internetowych zaimplementowano jednak bardziej rygorystyczne zasady. Dlaczego?

Co również bardzo istotne:

Certyfikaty wieloznaczne są obsługiwane przez dostawców przeglądarek i klientów TLS w taki sam sposób a interpretacja ich obsługi została całkowicie narzucona właśnie przez te podmioty, dlatego jakiekolwiek zmiany i odłamy w tej materii musiałyby zostać przyjęte przez wszystkie możliwe programy klienckie co jest raczej bardzo mało realne.

Wracając do RFC, to oba dokumenty zostało wyparte przez nowsze, takie jak RFC 5280 [IETF] i RFC 6125 [IETF]. Pierwszy z nich opisuje szczegóły dotyczące infrastruktury PKI oraz jasno wskazuje na pewne nieścisłości w standardach i istniejących implementacjach:

Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics.

Wskazuje on także, że niemożliwe jest posiadanie certyfikatu wildcard dla zagnieżdżonych subdomen. Przeglądarki opierają się głównie na RFC 6125, które definiuje nazwy wieloznaczne w nazwach domen (rozdział 6.4.3. Checking of Wildcard Certificates) i tak jak wspomniałem, wręcz sprzeciwia się certyfikatom wildcard głównie ze względów bezpieczeństwa i także wskazuje na brak jasnych definicji w obecnych specyfikacjach (rozdział 7.2. Wildcard Certificates).

Moim zdaniem kluczowe jest także stanowisko i wymagania konsorcjum CA/Browser Forum opisane w dokumencie Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, który jasno określa wymagania oraz znaczenie nazw wieloznacznych (strona 11 i 12):

Wildcard Certificate: A Certificate containing an asterisk (*) in the left-most position of any of the Subject Fully-Qualified Domain Names contained in the Certificate.

Wildcard Domain Name: A Domain Name consisting of a single asterisk character followed by a single full stop character ("*.") followed by a Fully-Qualified Domain Name.

Jest to chyba główny powód, dla którego przeglądarki stoją za zasadą „tylko jeden poziom dla symboli wieloznacznych” i ograniczają ich zakres (zezwolenie na wiele etykiet wieloznacznych prawdopodobnie naruszyłoby te wymagania). Zgodnie z tym, w skrajnym lewym fragmencie nazwy domenowej dozwolony jest tylko jeden symbol wieloznaczny, dlatego poprawnymi nazwami domenowymi są:

Natomiast nazwy, które nie są zgodne i nie powinny być stosowane, to:

Co więcej, istotny w zrozumieniu poziomów i nazw wieloznacznych jest poniższy fragment RFC 6125:

The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net).

Zgodnie z tym dokumentem, wymaga się, aby klienci weryfikujący certyfikaty oceniali użycie symbolu wieloznacznego tylko w skrajnej lewej (najniższej) części nazwy domeny. Dlatego nazwa *.a.yoursite.com jest prawidłowa, ale sub.*.yoursite.com już nie.

Jak widzisz, standardy mówią, że * powinien pasować do minimum jednego znaku bez kropek. Dlatego domena główna musi być alternatywną nazwą, aby mogła być chroniona tym samym certyfikatem. Wniosek z tego taki, że fragment domeny jest elementem zamkniętym, czyli *.com (2 etykiety) nie pasuje do sub.yoursite.com (3 etykiety).

W przypadku certyfikatu dla *.yoursite.com:

Jak to w końcu jest? #

W praktyce semantyka dopasowania nazwy podmiotu z symbolem wieloznacznym jest całkowicie narzucona przez przeglądarki internetowe i klientów TLS, przez co symbol wieloznaczny w nazwie odzwierciedla tylko jedną etykietę i można pozostawić go tylko od lewej strony do pierwszego znaku separatora, którym jest kropka, przez co działają one tylko w przypadku bezpośrednich subdomen znajdujących się na skrajnej lewej pozycji nazwy domeny.

Domena poziomu głównego nigdy nie jest obsługiwana przez subdomenę lub symbol wieloznaczny subdomeny. Zasadniczo wszystko, co pojawia się przed domeną główną, wskazuje na subdomenę, nie modyfikując domeny głównej.

W takim przypadku, symbol wieloznaczny jest ważny tylko dla sub.yoursite.com, ale już nie dla www.subdomain.yoursite.com ani yoursite.com (co jest kolejną odpowiedzią na nasze pytanie).

Zgodnie z tym, *.*.yoursite.com lub www.*.yoursite.com także nie będą chronione certyfikatem wildcard wystawionym dla *.yoursite.com.

Aby zabezpieczyć samą nazwę domeny i hosty w domenie, musisz uzyskać certyfikat z nazwami w rozszerzeniu SAN.

Pamiętajmy jednak, że nie wszystkie przeglądarki używają tych samych reguł i zasady, którymi się kierują, również nie są solidnie udokumentowane. Co więcej, te niejednoznaczności mogą wprowadzać możliwe do wykorzystania różnice w zachowaniu sprawdzania tożsamości między implementacjami klientów i wymuszać zbyt złożone i nieefektywne algorytmy sprawdzania tożsamości.

Urzędy certyfikacji również nakładają własne ograniczenia. Jednym z nich jest niechęć do wydawania zbyt szerokich certyfikatów z symbolami wieloznacznymi i to nie tylko ze względu na kwestie zaufania i bezpieczeństwa, ale także kwestie ekonomiczne (użytkownicy wolą kupować certyfikaty wieloznaczne właśnie po to, aby uniknąć kupowania wielu pojedynczych certyfikatów, co dla urzędów certyfikacji jest mało opłacalne).

Jeżeli chodzi o domenę główną, to niektórzy dostawcy automatycznie proponują jej dodanie jako alternatywną nazwę podmiotu (pole SAN) do wieloznacznego certyfikatu SSL, dzięki czemu możliwe jest objęcie domeny podstawowej wraz ze wszystkimi jej poddomenami pierwszego poziomu jednym certyfikatem. Możesz jednak samemu zażądać certyfikatu, który chroni dodatkowo domenę główną, określając w żądaniu wiele nazw domen. Na przykład możesz zażądać certyfikatu chroniącego yoursite.com i *.yoursite.com. Na przykład:

issuer: RapidSSL RSA CA 2018 (DigiCert Inc)
cn: yoursite.com
san: *.yoursite.com yoursite.com

W takim przypadku należy jednak zapoznać się ze specyfikacją RFC 2818 [IETF]. Ten dokument jasno określa, że nazwa pospolita powinna być używana tylko wtedy, gdy nie są skonfigurowane żadne alternatywne nazwy podmiotów, ale zezwala na stosowanie symboli wieloznacznych w rozszerzeniu SAN. Stąd jak widzisz, możliwe jest połączenie kilku certyfikatów innych niż symbole wieloznaczne i certyfikatów wieloznacznych w części SAN jednego certyfikatu czego potwierdzeniem niech będzie testowe połączenie z domeną outlook.com:

ssl: on, version(TLSv1.2), cipher(ECDHE-RSA-AES256-GCM-SHA384), temp_key(ECDH,P-384,384bits)
public-key(2048 bit), signature(sha256WithRSAEncryption)
date: Jun 21 00:00:00 2020 GMT / Jun 21 12:00:00 2022 GMT (650 days to expired)
issuer: DigiCert Cloud Services CA-1 (DigiCert Inc)
owner: Microsoft Corporation
cn: outlook.com
san: *.internal.outlook.com *.outlook.com outlook.com office365.com *.office365.com
*.outlook.office365.com *.office.com outlook.office.com substrate.office.com
attachment.outlook.live.net attachment.outlook.office.net attachment.outlook.officeppe.net
attachments.office.net *.clo.footprintdns.com *.nrb.footprintdns.com
ccs.login.microsoftonline.com ccs-sdf.login.microsoftonline.com substrate-sdf.office.com
attachments-sdf.office.net *.live.com mail.services.live.com hotmail.com *.hotmail.com
sni: match
validity: match
└─0:outlook.com a3c08ece ★
  ├   DigiCert Cloud Services CA-1 cbdb3b84
  └─1:DigiCert Cloud Services CA-1 cbdb3b84 ✓
    └ DigiCert Global Root CA 3513523f

Wygląda na to, że różne urzędy certyfikacji mają różne zasady dotyczące tworzenia certyfikatów łączących symbole wieloznaczne z dokładnymi nazwami domen: Thawte twierdzi, że mieszanie nie jest możliwe (patrz: Wildcard and SAN: Understanding Multi-Use SSL Certificates) i zaleca stosowanie certyfikatów SAN/UCC, które jednak można łączyć z symbolem wieloznacznym, o czym wspomniano w artykule Can I Use Wildcard Domains in My UCC Certificate?. Natomiast DigiCert propaguje umieszczanie domen typu wildcard jako jedne z zalecanych (patrz: Wildcard Certificates and Subject Alternate Names (SANs)).

Inną interesującą rzeczą jest też to, że możesz mieć wiele nazw z symbolami wieloznacznymi w tym samym certyfikacie, tzn. możesz mieć *.yoursite.com i *.subdomain.yoursite.com obsługiwane z poziomu tego samego certyfikatu. Powinieneś nie mieć problemu ze znalezieniem urzędu certyfikacji, który wyda taki certyfikat, a większość klientów powinna go zaakceptować.

Natomiast nie ma możliwości, i sam nigdy nie widziałem takiego certyfikatu w środowisku produkcyjnym, aby chronić domeny *.*.yoursite.com. Rozwiązaniem tego jest najprawdopodobniej certyfikat obsługujący *.yoursite.com, *.foo.yoursite.com czy *.bar.yoursite.com jednak widzisz, że jest to pozbawione sensu, ponieważ (jak już stwierdziliśmy na początku tego wpisu) certyfikaty typu wildcard są certyfikatami klucza publicznego wydawanymi na podstawie „nieznanych potomków” poddomeny. Ten sposób został zresztą opisany w artykule Can I Create a *.subdomain.domain.com Wildcard? How About *.*.subdomain.com?.

Pamiętajmy też, że certyfikaty typu wildcard nie są dozwolone w przypadku certyfikatów EV. Na koniec tego wpisu polecam ciekawy artykuł Can You Create A Wildcard SSL Certificate For Two Levels? oraz zalecenia i uwagi w kontekście nazw wieloznacznych i domen najwyższego poziomu zawarte w dokumencie Redirection in the COM and NET domains zdefiniowane przez organizację ICANN.

Podobne posty