Din klient afviser et certifikat, hvis kæde valideres rent, og fejlen siger, at navnet ikke stemmer overens. Den besked handler ikke om, hvem der har signeret certifikatet. Den handler om udvidelsen med alternative emnenavne, som bærer de identiteter, certifikatet må repræsentere, og om den identitet, du har konfigureret, optræder der i den rigtige form. Tillid svarer på, hvem der signerede det, mens navnekontrollen svarer på, hvilken vært det hører til.

Hvad klienten faktisk sammenligner

Klienten omdanner din konfiguration til en referenceidentitet: et værtsnavn, en adresse eller en protokolspecifik identifikator. Derefter søger den efter den identitet i certifikatet og anvender matchreglerne for den protokol, der bruges. Kun poster af samme type tæller, så en DNS-post kan ikke opfylde en adresse, og sammenligningen sker, uanset om et menneske nogensinde ser på certifikatet.

Når referenceidentiteten mangler i den udvidelse, fejler kontrollen, selv om det gamle fællesnavn stemmer. Et certifikat kan være legitimt udstedt til en virksomhed og stadig være det forkerte for vpn.example.com, hvis navnet aldrig blev inkluderet. Fejlen er en navnemismatch, selv om certifikatet er ægte.

DNS-navne og IP-adresser er separate poster

En profil, der peger på 203.0.113.10, mens certifikatet kun lister vpn.example.com, afvises, fordi pakkerne ankommer, men identiteten ikke stemmer. DNS-navne og adresseliteral opbevares som forskellige posttyper, og den ene erstatter aldrig den anden. Derfor kan en tjeneste være nåelig via adresse og alligevel ubrugelig gennem en profil, der bruger den adresse.

Jokertegn følger også deres egne regler: et jokertegn dækker en enkelt label, ikke alle navne under et domæne. DNS-sammenligning er ikke sagsfølsom, mens andre identifikatortyper er det, så en værdi, der ser identisk ud på skærmen, kan fejle en streng sammenligning. Kontroller matchreglerne for den identitetstype, der bruges, i stedet for at sammenligne strenge med øjet. At tilføje et navn til udvidelsen er en udstedelsesbeslutning, ikke noget en klientindstilling kan levere.

Undersøg det certifikat, forbindelsen faktisk brugte

Læs det materiale, det levende endepunkt præsenterer, ikke en fil kopieret fra en administrationsside. En load balancer eller en erstatningsinstans kan præsentere noget andet end det certifikat, der blev uploadet for måneder siden, og den forskel er usynlig i en konsol.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

Blokken med alternative emnenavne, udstederkæden og gyldighedsperioden hører til samme læsning, fordi en navnemismatch og en udløbsdato giver forskellige fejl. Sammenlign hvert navn i den blok med den identitet, der er konfigureret i profilen, tegn for tegn, og noter, hvilken type det er. Gentages kommandoen mod endepunktets adresseform, viser det, om certifikatet dækker begge identiteter eller kun én. En venlig emnevisning i en administrationskonsol er ikke et valideringsresultat og siger intet om, hvilke navne udvidelsen indeholder.

Det fælles navn er ikke den moderne sandhedskilde

Browsere og de fleste TLS-biblioteker ignorerer nu det fælles navn til værtsnavnematchning og spørger i stedet udvidelsen. Nogle VPN-klienter sammenligner stadig det fælles navn først eller falder tilbage til det, når udvidelsen mangler, og det er derfor, et certifikat kan bestå i en browser og fejle i en klient. Den samme navnekontrol kan bestå på én platform og fejle på en anden, uden at certifikatet ændrer sig overhovedet.

Find ud af, hvilket felt din klient læser, før du beslutter, at certifikatet er forkert. To klienter på samme endepunkt kan være uenige, og uenigheden er information om klienten snarere end om certifikatet.

Reparer udstedelsen eller profilen, ikke kontrollen

Når en profil er bygget op omkring et alias, skal du enten pege den på det dokumenterede værtsnavn eller genudstede certifikatet til aliaset og udrulle det i et planlagt vindue. At dæmpe advarslen er ikke en tredje mulighed, fordi kontrollen er det eneste trin, der binder et signeret certifikat til netop denne vært. At fjerne den betyder, at ethvert certifikat fra samme myndighed kan stå i stedet for den server, du ville nå.

Fornyelse bør bevare de tilsigtede navne og formålet i stedet for blot at flytte udløbsdatoen frem. En fornyelse, der dropper et navn, er et nyt nedbrud planlagt til næste genstart, og det kommer normalt uden varsel, fordi det gamle certifikat stadig var gyldigt, da ændringen blev foretaget.

Registrer den forventede identitet, de navne, der blev præsenteret, og den kæde, der signerede dem. Den registrering gør den næste fornyelse til en sammenligning i stedet for en undersøgelse. Udvidelsesdefinitionen står i RFC 5280, hvis du skal kontrollere en bestemt udstedelse.

Relaterede artikler