ca md too weak: certificaat opnieuw uitgeven of het niveau verlagen?

OpenVPN client die vorige maand nog werkte, faalt nu bij het opstarten met ca md too weak, en het profiel op schijf is byte voor byte hetzelfde als wat werkte. De melding gaat over de handtekening op het certificaat van een certificaatautoriteit, niet over het gegevenscijfer, de auth-digest of het accountwachtwoord. Drie voorwaarden bepalen of de oplossing nieuwe identiteitsgegevens, een nieuwe keten of een bewuste beleidswijziging is. Werk ze in volgorde af, en je vermijdt de gebruikelijke uitkomst waarbij de tunnel terugkomt door elke TLS-verbinding op de host te verzwakken.

Wat de fout werkelijk benoemt

OpenSSL gooit deze verificatiefout tijdens het opbouwen van een keten, wanneer het certificaat dat als CA optreedt een handtekening-digest draagt die het beveiligingsniveau van de bibliotheek niet meer accepteert. MD5 wordt op het standaardniveau geweigerd, en SHA-1 wordt geweigerd zodra het niveau wordt verhoogd. De digest op het bladcertificaat is hier minder belangrijk dan de digest op de uitgever die het ondertekent. Hetzelfde beleid kan een root weigeren die op de dag van uitgifte volstrekt gewoon was.

Daarom doet het bewerken van auth of data-ciphers niets voor deze fout. Die instellingen bepalen hoe pakketten na de handshake worden beschermd, terwijl het geweigerde object een identiteitsdocument is dat wordt onderzocht voordat er een tunnel bestaat. Een certificaat kan comfortabel binnen zijn geldigheidsvenster zitten en toch een handtekening dragen die de bibliotheek niet accepteert.

Houd de controles apart in je hoofd en de fout houdt op mysterieus te lijken. Geldigheidsdatums, sleutelgebruik en handtekening-digest zijn onafhankelijke tests, en precies één ervan is zojuist mislukt.

Voorwaarde één: is het geweigerde object de root?

Druk elk certificaat in het profiel af en lees de velden subject en issuer. Een zelfondertekende root toont in beide dezelfde waarde, en het handtekeningalgoritme ervan is waar de hele keten op rust. Zit de zwakke digest daar, dan erft elk blad eronder het probleem. Schrijf het algoritme naast subject, zodat de latere vergelijking mechanisch is en niet uit het geheugen komt.

Gebundelde CA-bestanden bevatten vaak meerdere blokken, dus bepaal welk blok werkelijk wordt geladen in plaats van aan te nemen dat de eerste schuldig is. Het commando openssl x509 -in ca.pem -noout -subject -issuer -text beschrijft één certificaat per keer, wat betekent dat de bundel eerst moet worden gesplitst als er meer in staan. Vergelijk het afgedrukte handtekeningalgoritme met de digest die je uit het tijdperk van de root zou verwachten.

Een blad dat met SHA-256 onder een zwakke root is ondertekend, faalt nog steeds, omdat de ketencontrole helemaal naar boven loopt. Die volgorde is wat de volgende voorwaarde belangrijk maakt.

Voorwaarde twee: beheer je de uitgever?

Hoort de root bij je eigen organisatie, dan is de duurzame oplossing een nieuwe root met een moderne digest plus opnieuw uitgegeven bladen, geleverd als één profielupdate. Dat kost een onderhoudsvenster en een plan voor apparaten die de update niet dezelfde dag kunnen verwerken.

Heeft een derde partij de keten uitgegeven, dan is de oplossing een verzoek aan die operator, en de enige nuttige lokale actie is stoppen met vertrouwen op het oude materiaal. Het bewerken van de PEM-tekst of het opnieuw opslaan van het bestand verandert niets aan wat de handtekening dekt.

Eén tussenliggend geval verdient een naam: een interne root die ouder is dan de huidige standaarden maar nog steeds materiaal ondertekent dat andere systemen vertrouwen. Die vervangen betekent elke afnemer auditen, inclusief apparaten die het oude certificaat op vingerafdruk vastpinnen. Tel die afnemers voordat je de wijziging plant, want een rootwissel die er één mist, ruilt een opstartfout in voor een storing.

Voorwaarde drie: wat het verlagen van het niveau ook accepteert

Het verlagen van het beveiligingsniveau, of het kiezen van het legacy-certificaatprofiel van OpenVPN, zorgt dat de client de oude digest weer accepteert. Het versoepelt ook andere controles in dezelfde bibliotheek, voor elke verbinding die dat proces maakt.

Dat kan verdedigbaar zijn in een lab, of als korte brug terwijl vervangend materiaal wordt voorbereid, zolang de uitzondering tot één profiel beperkt blijft en een einddatum heeft. Als blijvende instelling op een gedeelde host verbreedt het stilzwijgend wat elke TLS-client daar vertrouwt.

Schrijf de uitzondering op met een eigenaar en een verwijderstap. Een ongedocumenteerde niveauwijziging is zes maanden later niet te onderscheiden van een fout, en de volgende engineer weet niet dat het ooit een beslissing was.

De beslissing, opgeschreven als regel

Vervang de keten wanneer je de uitgever beheert en zijn afnemers kunt opsommen. Escaleer naar de uitgever wanneer je dat niet doet. Verlaag het niveau alleen als gedateerde, afgebakende uitzondering met de vervanging al ingepland. Al het andere laat hetzelfde certificaat staan en verplaatst het risico naar iets minder zichtbaars.

Test het profiel daarna opnieuw vanaf een schone client, bevestig dat de handshake voltooit, en bewaar de exacte weigeringstekst als het nog steeds faalt. Een precieze foutmelding is het goedkoopste dat je kunt doorgeven aan wie de volgende laag beheert.