ca md too weak: utstede sertifikatet på nytt eller senke nivået?
Feilen navngir et signaturdigest klienten nå avviser, ikke et svakt passord. Velg mellom å utstede kjeden på nytt, spørre utstederen eller senke policyen.
OpenVPN klient som fungerte i forrige måned feiler nå ved oppstart med ca md too weak, og profilen på disken er byte for byte den samme som virket. Meldingen gjelder signaturen på sertifikatet til en sertifikatmyndighet, ikke datachifferet, auth-digesten eller kontopassordet. Tre forhold avgjør om løsningen er nytt identitetsmateriell, en ny kjede eller en bevisst policyendring. Ta dem i rekkefølge, og du unngår det vanlige utfallet der tunnelen kommer tilbake ved å svekke hver TLS-tilkobling på verten.
Hva feilen egentlig navngir
OpenSSL reiser denne verifiseringsfeilen mens den bygger en kjede, når sertifikatet som opptrer som CA har et signaturdigest som bibliotekets sikkerhetsnivå ikke lenger godtar. MD5 avvises på standardnivået, og SHA-1 avvises når nivået heves. Digesten på løvsertifikatet betyr mindre her enn digesten på utstederen som signerer det. Den samme policyen kan avvise en rot som var helt vanlig den dagen den ble utstedt.
Det er derfor redigering av auth eller data-ciphers ikke gjør noe for denne feilen. Disse innstillingene styrer hvordan pakker beskyttes etter håndtrykket, mens det avviste objektet er et identitetsdokument som undersøkes før en tunnel finnes. Et sertifikat kan ligge komfortabelt innenfor gyldighetsvinduet og likevel bære en signatur biblioteket ikke vil godta.
Hold sjekkene atskilt i hodet, så slutter feilen å virke mystisk. Gyldighetsdatoer, nøkkelbruk og signaturdigest er uavhengige tester, og nøyaktig én av dem har nettopp feilet.
Første forhold: er det avviste objektet roten?
Skriv ut hvert sertifikat i profilen og les subject- og issuer-feltene. En selvsignert rot viser samme verdi i begge, og signaturalgoritmen er den hele kjeden hviler på. Når den svake digesten sitter der, arver hvert løv under den problemet. Skriv algoritmen ved siden av subject slik at senere sammenligning blir mekanisk og ikke fra hukommelsen.
Samlede CA-filer inneholder ofte flere blokker, så identifiser blokken som faktisk lastes i stedet for å anta at den første er skyldig. Kommandoen openssl x509 -in ca.pem -noout -subject -issuer -text beskriver ett sertifikat om gangen, noe som betyr at bunten må deles først hvis den inneholder flere. Sammenlign den utskrevne signaturalgoritmen med digesten du ville forvente fra æraen roten ble laget i.
Et løv signert med SHA-256 under en svak rot feiler fortsatt, fordi kjedekontrollen går helt til topps. Den rekkefølgen er det som gjør neste forhold viktig.
Andre forhold: kontrollerer du utstederen?
Hvis roten tilhører organisasjonen din, er den varige løsningen en ny rot med moderne digest pluss nye løv, levert som én profiloppdatering. Det koster et vedlikeholdsvindu og en plan for enheter som ikke kan ta oppdateringen samme dag.
Hvis en tredjepart utstedte kjeden, er løsningen en forespørsel til den operatøren, og den eneste nyttige lokale handlingen er å slutte å stole på det gamle materiellet. Å redigere PEM-teksten eller lagre filen på nytt endrer ingenting av det signaturen dekker.
Ett mellomtilfelle fortjener navn: en intern rot som er eldre enn dagens standarder men fortsatt signerer materiell andre systemer stoler på. Å erstatte den betyr å revidere hver forbruker, inkludert apparater som fester det gamle sertifikatet med fingeravtrykk. Tell forbrukerne før du planlegger endringen, for en rotutveksling som overser én bytter en oppstartsfeil mot et avbrudd.
Tredje forhold: hva senking av nivået også godtar
Å senke sikkerhetsnivået, eller velge OpenVPNs legacy-sertifikatprofil, får klienten til å godta den gamle digesten igjen. Det lemper også på andre kontroller i samme bibliotek, for hver tilkobling den prosessen gjør.
Det kan forsvares i et laboratorium, eller som en kort bro mens erstatningsmateriell forberedes, så lenge unntaket er avgrenset til én profil og har en sluttdato. Som permanent innstilling på en delt vert utvider det stille det hver TLS-klient der vil stole på.
Skriv ned unntaket med eier og et fjerningssteg. En udokumentert nivåendring kan ikke skilles fra en feil seks måneder senere, og neste ingeniør vil ikke vite at det noen gang var en beslutning.
Beslutningen, skrevet som en regel
Erstatt kjeden når du kontrollerer utstederen og kan liste opp forbrukerne. Eskaler til utstederen når du ikke gjør det. Senk nivået bare som et datert, avgrenset unntak med erstatningen allerede planlagt. Alt annet lar det samme sertifikatet bli stående og flytter risikoen et mindre synlig sted.
Test deretter profilen på nytt fra en ren klient, bekreft at håndtrykket fullføres, og ta vare på den nøyaktige avvisningsteksten hvis den fortsatt feiler. En presis feilmelding er det billigste du kan gi videre til den som eier neste lag.