ca md too weak: utfärda certifikatet igen eller sänka nivån?

OpenVPN klient som fungerade förra månaden misslyckas nu vid start med ca md too weak, och profilen på disken är byte för byte densamma som fungerade. Meddelandet gäller signaturen på ett certifikat från en certifikatutfärdare, inte datachiffret, auth-digesten eller kontolösenordet. Tre villkor avgör om åtgärden är nytt identitetsmaterial, en ny kedja eller en medveten policyändring. Ta dem i ordning, så undviker du det vanliga utfallet där tunneln kommer tillbaka genom att försvaga varje TLS-anslutning på värden.

Vad felet egentligen namnger

OpenSSL reser detta verifieringsfel medan det bygger en kedja, när certifikatet som agerar CA bär en signaturdigest som bibliotekets säkerhetsnivå inte längre accepterar. MD5 avvisas på standardnivån, och SHA-1 avvisas när nivån höjs. Digesten på lövcertifikatet betyder mindre här än digesten på utfärdaren som signerar det. Samma policy kan avvisa en rot som var helt vanlig den dag den utfärdades.

Det är därför redigering av auth eller data-ciphers inte gör något för detta fel. De inställningarna styr hur paket skyddas efter handskakningen, medan det avvisade objektet är ett identitetsdokument som granskas innan en tunnel finns. Ett certifikat kan ligga bekvämt inom sitt giltighetsfönster och ändå bära en signatur som biblioteket inte accepterar.

Håll kontrollerna åtskilda i huvudet och felet slutar verka mystiskt. Giltighetsdatum, nyckelanvändning och signaturdigest är oberoende tester, och exakt en av dem har just fallerat.

Första villkoret: är det avvisade objektet roten?

Skriv ut varje certifikat i profilen och läs fälten subject och issuer. En självsignerad rot visar samma värde i båda, och dess signaturalgoritm är den hela kedjan vilar på. När den svaga digesten sitter där ärver varje löv under den problemet. Skriv algoritmen bredvid subject så att jämförelsen senare blir mekanisk och inte från minnet.

Samlade CA-filer innehåller ofta flera block, så identifiera blocket som faktiskt laddas i stället för att anta att det första är skyldigt. Kommandot openssl x509 -in ca.pem -noout -subject -issuer -text beskriver ett certifikat i taget, vilket innebär att buntet först måste delas om det innehåller fler. Jämför den utskrivna signaturalgoritmen med den digest du skulle förvänta dig från epoken då roten skapades.

Ett löv signerat med SHA-256 under en svag rot misslyckas fortfarande, eftersom kedjekontrollen går hela vägen upp. Den ordningen är vad som gör nästa villkor viktigt.

Andra villkoret: kontrollerar du utfärdaren?

Om roten tillhör din organisation är den varaktiga lösningen en ny rot med modern digest plus nya löv, levererade som en enda profiluppdatering. Det kostar ett underhållsfönster och en plan för enheter som inte kan ta uppdateringen samma dag.

Om en tredje part utfärdade kedjan är lösningen en begäran till den operatören, och den enda användbara lokala åtgärden är att sluta lita på det gamla materialet. Att redigera PEM-texten eller spara filen igen ändrar ingenting av det som signaturen täcker.

Ett mellanting förtjänar ett namn: en intern rot som är äldre än dagens standardvärden men fortfarande signerar material som andra system litar på. Att byta ut den innebär att granska varje konsument, inklusive apparater som fäster det gamla certifikatet med fingeravtryck. Räkna konsumenterna innan du planerar ändringen, för ett rotbyte som missar en byter ett startfel mot ett avbrott.

Tredje villkoret: vad sänkningen av nivån också accepterar

Att sänka säkerhetsnivån, eller välja OpenVPNs äldre certifikatprofil, får klienten att acceptera den gamla digesten igen. Det luckrar också upp andra kontroller i samma bibliotek, för varje anslutning den processen gör.

Det kan vara försvarbart i ett labb, eller som en kort bro medan ersättningsmaterial förbereds, så länge undantaget är begränsat till en profil och har ett slutdatum. Som permanent inställning på en delad värd vidgar det tyst vad varje TLS-klient där kommer att lita på.

Skriv ned undantaget med en ägare och ett borttagningssteg. En odokumenterad nivåändring går inte att skilja från ett misstag sex månader senare, och nästa ingenjör vet inte att det någon gång var ett beslut.

Beslutet, skrivet som en regel

Ersätt kedjan när du kontrollerar utfärdaren och kan räkna upp dess konsumenter. Eskalera till utfärdaren när du inte gör det. Sänk nivån bara som ett daterat, avgränsat undantag med ersättningen redan planerad. Allt annat lämnar samma certifikat på plats och flyttar risken någonstans mindre synligt.

Testa sedan om profilen från en ren klient, bekräfta att handskakningen slutförs, och behåll den exakta avvisningstexten om det fortfarande misslyckas. Ett exakt felmeddelande är det billigaste du kan lämna vidare till den som äger nästa lager.