Unable to load PEM file. See https://cryptography.io/en/latest/faq/#why-can-t-i-import-my-pem-file for more details. MalformedFraming

Der Satz vor dem Token ist fest; das Token benennt, was schiefgelaufen ist. MalformedFraming bedeutet, dass die BEGIN/END-Zeilen nicht gefunden wurden; MismatchedTags("PRIVATE KEY", "PUBLIC KEY") bedeutet, dass sie nicht zueinander passen; InvalidData(Invalid symbol 92, offset 0.) bedeutet, dass der Inhalt kein base64 ist – 92 ist ein Backslash, das Kennzeichen wörtlicher Zeichenfolgen \n.

Python cryptography — ValueError from load_pem_* functions

Was der Fehler bedeutet

load_pem_private_key / load_pem_public_key / load_pem_x509_certificate haben keinen intakten PEM-Rahmen gefunden – zueinander passende BEGIN- und END-Zeilen mit base64-Inhalt dazwischen. Das Token am Ende (hier MalformedFraming) ist die Diagnose des Parsers; der FAQ-Link steht direkt im Fehlertext.

Warum der Fehler auftritt

• Abgeschnittenes oder unvollständig kopiertes PEM

  häufig

  Eine fehlende END-Zeile (Zwischenablage abgeschnitten, ein YAML-Blockskalar verschluckt die letzte Zeile) zerstört den Rahmen. Jedes PEM muss mit seiner passenden Zeile -----END ...----- enden. Ein leerer Wert – ein nicht gesetztes Secret – erzeugt dasselbe MalformedFraming.

• Maskierte Zeilenumbrüche aus Umgebungsvariablen oder Konfiguration

  häufig

  PEMs, die über .env-Dateien, docker-compose, Kubernetes-Manifeste oder JSON geliefert werden, kommen oft als eine einzige Zeile mit wörtlichen Zeichenfolgen \n an. Die Ladefunktion meldet denselben Satz mit InvalidData(Invalid symbol 92, offset 0.) am Ende.

• Beschädigte BEGIN- oder END-Markierungen

  gelegentlich

  Eine Markierung, der ein Bindestrich fehlt, oder ähnlich aussehende Striche, die aus einer Textverarbeitung eingefügt wurden, rahmen den Block nicht mehr ein; ein END-Label, das vom BEGIN-Label abweicht, wird als MismatchedTags gemeldet. Was cryptography 50 toleriert: Anführungszeichen um den Block, YAML-Einrückung, eine UTF-8-BOM und CRLF-Zeilenenden.

• Zusammengefügtes Bundle mit beschädigter Trennstelle

  selten

  Kettendateien mit mehreren PEM-Blöcken scheitern als Ganzes, wenn ein Block seine END-Zeile verloren hat – die Ladefunktion meldet dann InvalidData(Invalid symbol 45, …), wobei 45 der erste Bindestrich der nächsten BEGIN-Zeile ist. Die Ladefunktion meldet die Datei, nicht den Block – grenze den Fehler also durch Halbieren ein: Teile das Bundle auf und lade jedes Objekt einzeln, um das beschädigte zu finden.

So behebst du den Fehler

1. 1.

   Vor dem Laden normalisieren

   Stelle die Zeilenumbrüche wieder her, entferne Whitespace und Anführungszeichen und prüfe die erste Zeile, bevor du die Bytes an die Ladefunktion übergibst.

   import os
   pem = os.environ["PRIVATE_KEY"].replace("\\n", "\n").strip().strip('"').encode()
   assert pem.startswith(b"-----BEGIN"), pem[:30]
   
   from cryptography.hazmat.primitives.serialization import load_pem_private_key
   key = load_pem_private_key(pem, password=None)

2. 2.

   Dateien oder native mehrzeilige Secrets bevorzugen

   Eingebundene Secret-Dateien vermeiden das Problem mit der Maskierung vollständig; Kubernetes-Secrets und die meisten Vaults können das PEM bytegenau liefern.

   with open("/run/secrets/signing_key.pem", "rb") as f:
       key = load_pem_private_key(f.read(), password=None)

3. 3.

   Rahmen automatisiert prüfen

   Eine schnelle Prüfung, ob die BEGIN/END-Zeilen vorhanden sind und zueinander passen, grenzt den Fehler ein: Inhalt oder Übertragung.

   lines = pem.decode().splitlines()
   print(lines[0])   # -----BEGIN PRIVATE KEY-----
   print(lines[-1])  # -----END PRIVATE KEY-----

← Gesamte Signaturfehler-Datenbank durchsuchen