OpenVPN klient, der virkede i sidste måned, fejler nu ved opstart med ca md too weak, og profilen på disken er byte for byte den samme, som virkede. Beskeden handler om signaturen på en certifikatmyndigheds certifikat, ikke om datacifret, auth-digestet eller kontoadgangskoden. Tre betingelser afgør, om løsningen er nyt identitetsmateriale, en ny kæde eller en bevidst politikændring. Tag dem i rækkefølge, og du undgår det sædvanlige udfald, hvor tunnelen kommer tilbage ved at svække hver TLS-forbindelse på værten.

Hvad fejlen egentlig navngiver

OpenSSL rejser denne verifikationsfejl, mens den bygger en kæde, når certifikatet, der optræder som CA, bærer et signaturdigest, som bibliotekets sikkerhedsniveau ikke længere accepterer. MD5 afvises på standardniveauet, og SHA-1 afvises, når niveauet hæves. Digestet på bladcertifikatet betyder mindre her end digestet på den udsteder, der signerer det. Samme politik kan afvise en rod, der var helt almindelig den dag, den blev udstedt.

Derfor gør redigering af auth eller data-ciphers intet for denne fejl. De indstillinger styrer, hvordan pakker beskyttes efter handshaket, mens det afviste objekt er et identitetsdokument, der undersøges før en tunnel findes. Et certifikat kan ligge trygt inden for sin gyldighedsperiode og stadig bære en signatur, som biblioteket ikke vil acceptere.

Hold kontrollerne adskilt i hovedet, og fejlen holder op med at virke mystisk. Gyldighedsdatoer, nøglebrug og signaturdigest er uafhængige test, og præcis én af dem er netop fejlet.

Betingelse et: er det afviste objekt roden?

Udskriv hvert certifikat i profilen og læs felterne subject og issuer. En selvsigneret rod viser samme værdi i begge, og dens signaturalgoritme er den, hele kæden hviler på. Når det svage digest sidder der, arver hvert blad nedenunder problemet. Skriv algoritmen ved siden af subject, så den senere sammenligning bliver mekanisk i stedet for husket.

Samlede CA-filer indeholder ofte flere blokke, så identificer den blok, der faktisk indlæses, i stedet for at antage, at den første er skyldig. Kommandoen openssl x509 -in ca.pem -noout -subject -issuer -text beskriver ét certifikat ad gangen, hvilket betyder, at bundtet først skal deles, hvis det indeholder flere. Sammenlign den udskrevne signaturalgoritme med det digest, du ville forvente fra den æra, roden blev oprettet i.

Et blad signeret med SHA-256 under en svag rod fejler stadig, fordi kædekontrollen går helt op. Det er den rækkefølge, der gør den næste betingelse vigtig.

Betingelse to: kontrollerer du udstederen?

Hvis roden tilhører din organisation, er den holdbare løsning en ny rod med et moderne digest plus genudstedte blade, leveret som én profilopdatering. Det koster et vedligeholdelsesvindue og en plan for enheder, der ikke kan tage opdateringen samme dag.

Hvis en tredjepart udstedte kæden, er løsningen en anmodning til den operatør, og den eneste nyttige lokale handling er at holde op med at afhænge af det gamle materiale. Redigering af PEM-teksten eller ny gemning af filen ændrer intet af det, signaturen dækker.

Et mellemtilfælde fortjener et navn: en intern rod, der er ældre end de nuværende standarder, men stadig signerer materiale, som andre systemer stoler på. At erstatte den betyder at revidere hver forbruger, inklusive apparater, der pinner det gamle certifikat via fingeraftryk. Tæl de forbrugere, før du planlægger ændringen, for et rodskifte, der misser én, bytter en opstartsfejl for et nedbrud.

Betingelse tre: hvad sænkning af niveauet også accepterer

At sænke sikkerhedsniveauet eller vælge OpenVPNs legacy-certifikatprofil får klienten til at acceptere det gamle digest igen. Det lemper også andre kontroller i samme bibliotek, for hver forbindelse den proces laver.

Det kan være forsvarligt i et laboratorium eller som en kort bro, mens erstatningsmateriale forberedes, så længe undtagelsen er begrænset til én profil og har en slutdato. Som permanent indstilling på en delt vært udvider det stille, hvad hver TLS-klient der vil stole på.

Skriv undtagelsen ned med en ejer og et fjernelsestrin. En udokumenteret niveauchange kan et halvt år senere ikke skelnes fra en fejl, og den næste ingeniør vil ikke vide, at det nogensinde var en beslutning.

Beslutningen, skrevet som en regel

Erstat kæden, når du kontrollerer udstederen og kan opregne dens forbrugere. Eskalér til udstederen, når du ikke kan. Sænk kun niveauet som en dateret, afgrænset undtagelse med erstatningen allerede planlagt. Alt andet lader det samme certifikat blive stående og flytter risikoen et mindre synligt sted hen.

Test derefter profilen igen fra en ren klient, bekræft at handshaket gennemføres, og gem den præcise afvisningstekst, hvis det stadig fejler. En præcis fejlmeddelelse er det billigste, du kan give den, der ejer det næste lag.

Relaterede artikler