Die Unterschiede zwischen .pfx, .p12, .cer und .crt werden detailliert erklärt.

Wenn Sie bis hierher gelesen haben, um die Unterschiede zwischen .pfx, .p12, .cer und .crt zu verstehen , sind Sie beim Installieren eines digitalen Zertifikats oder SSL-Zertifikats auf einem Server wahrscheinlich schon auf die eine oder andere ungewöhnliche Datei gestoßen. Damit sind Sie nicht allein: Bei all den Akronymen, Dateiendungen und Formaten kann man leicht den Überblick verlieren und nicht mehr wissen, wofür die einzelnen Dateien da sind oder welche man im jeweiligen Fall benötigt.

Die gute Nachricht ist: Auch wenn die Namen kompliziert klingen mögen, lässt sich alles ganz einfach erklären. Diese Dateien sind lediglich Container für Zertifikate und Schlüssel in verschiedenen Formaten (Text oder Binär) und für unterschiedliche Systeme ( Windows , Linux , Java, Browser usw.). Schauen wir sie uns in Ruhe nacheinander an und stellen wir die Zusammenhänge her, damit Sie genau wissen, was jede Datei ist, wofür sie dient und wie man sie gegebenenfalls verwendet oder konvertiert.

Was ist ein digitales Zertifikat und wie hängen die Dateiformate .pfx, .p12, .cer und .crt zusammen?

Ein digitales Zertifikat ist ein elektronisches Dokument, das von einer Zertifizierungsstelle (CA oder, gemäß der eIDAS-Verordnung, einem qualifizierten Dienstanbieter) unterzeichnet wird und eine Identität mit einem öffentlichen Schlüssel verknüpft. Diese Identität kann eine Person, ein Unternehmen, ein Webserver, eine Domain usw. sein.

Um diese Verbindung herzustellen , wird Public-Key- oder asymmetrische Kryptographie verwendet : Es gibt ein Schlüsselpaar, einen öffentlichen Schlüssel (den jeder kennen kann) und einen privaten Schlüssel (den nur der Besitzer haben sollte). Was mit dem öffentlichen Schlüssel verschlüsselt wurde, kann nur mit dem privaten Schlüssel entschlüsselt werden und umgekehrt. Dies ermöglicht Authentifizierung, Verschlüsselung und elektronische Signaturen.

Hinter all diesen Zertifikaten steht eine Public-Key-Infrastruktur (PKI) , die die Zertifizierungsstelle, Registrierungsstellen, Zertifikatsspeicher, Zertifikatssperrlisten (CRLs) und in vielen Umgebungen eine Zeitstempelstelle (TSA) zur Aufzeichnung des Signierzeitpunkts umfasst.

Die interne Struktur der überwiegenden Mehrheit der Allzweckzertifikate folgt dem X.509- Standard , der von der ITU definiert und in RFC 5280 detailliert beschrieben wird. Dieser Standard definiert Felder wie Version, Seriennummer, Signaturalgorithmus, Aussteller, Gültigkeitszeitraum, Subjekt, öffentlicher Schlüssel des Inhabers und mögliche zusätzliche Erweiterungen.

Hinsichtlich der Algorithmen verwenden Zertifikate typischerweise asymmetrische Kryptographie mit RSA, DSA oder ECDSA . RSA und ECDSA dienen sowohl der Signierung als auch der Verschlüsselung, während DSA sich auf die digitale Signatur und Verifizierung konzentriert.

Interne Formate und Erweiterungen: PEM, DER, CER, CRT und Company

Wenn wir von Erweiterungen wie .cer, .crt, .pem, .der, .pfx, .p12 oder .p7b sprechen , vermischen wir eigentlich zwei Konzepte: das Kodierungsformat des Zertifikats (Base64-Text oder Binär) und die Funktion der Datei (nur Zertifikat, Zertifikat + privater Schlüssel, Zertifikatskette usw.).

Auf der internen Formatebene werden X.509-Zertifikate mit ASN.1 dargestellt und typischerweise mit DER (binär) oder dessen textueller Variante PEM (DER, konvertiert in Base64 und mit BEGIN/END -Headern versehen ) kodiert. Darauf aufbauend haben verschiedene Systeme und Standards spezifische Container wie PKCS#7 (.p7b) oder PKCS#12 (.pfx, .p12) definiert.

Um Verwirrung zu vermeiden, ist es wichtig zu wissen, dass die Dateiendung oft nur eine Namenskonvention ist : Eine .cer- oder eine .crt-Datei kann genau dasselbe enthalten; nur wird die eine häufiger unter Windows und die andere eher in Unix/Linux-Umgebungen verwendet, um nur ein Beispiel zu nennen.

Innerhalb dieser allgemeinen Gruppe gibt es einige wichtige Formate , über die Sie sich unbedingt im Klaren sein sollten, da Ihnen diese bei der Arbeit mit SSL/TLS- oder persönlichen Zertifikaten ständig begegnen werden.

PEM-Format: der „lesbare Text“ von Zertifikaten

Das PEM-Format ist mit Abstand das gängigste Format für SSL/TLS-Zertifikate auf Servern wie Apache oder Nginx und wird von den meisten Sicherheitstools unterstützt. Eine PEM-Datei ist im Grunde eine DER-Datei, die in Base64 kodiert und von Textheadern umgeben ist . Dadurch lässt sie sich mit jedem Texteditor (Notepad, nano, vim usw.) öffnen und kopieren.

Eine PEM-Datei wird erkannt, weil ihr Inhalt durch Zeilen wie —–BEGIN CERTIFICATE—– und —–END CERTIFICATE—– begrenzt ist , wenn sie ein Zertifikat enthält, oder —–BEGIN PRIVATE KEY—– und —–END PRIVATE KEY—–, wenn sie einen privaten Schlüssel enthält. Der dazwischenliegende Text ist eine Base64-Zeichenkette, die die ursprünglichen Binärdaten repräsentiert.

Eine einzelne PEM-Datei kann entweder nur das Zertifikat , das Zertifikat inklusive der Zwischenzertifizierungsstellenkette, den privaten Schlüssel separat oder sogar das gesamte Paket (privater Schlüssel, Serverzertifikat, Zwischenzertifikate und Stammzertifikat) enthalten. Zertifikatsignierungsanforderungen ( CSRs ), die lediglich in Text umkodierte PKCS#10-Strukturen darstellen, werden ebenfalls in PEM-Dateien bereitgestellt.

Dieses Format wurde ursprünglich in den RFCs 1421-1424 im Rahmen des Projekts Privacy-enhanced Electronic Mail definiert, das sich für E-Mails nicht durchsetzte, aber ein hervorragendes Textformat für den Transport kryptografischer Daten auf bequeme, lesbare und einfach zu kopierende/einzufügende Weise hinterließ.

In der Praxis handelt es sich bei Dateien mit Erweiterungen wie .pem, .crt, .cer oder .key auf Unix/Linux-Systemen üblicherweise um PEM-Dateien. Typischerweise enthält die .key-Datei den privaten Schlüssel, die .crt- oder .cer-Datei das Serverzertifikat und manchmal eine zusätzliche PEM-Datei die Zwischenzertifizierungsstellenkette.

DER-Format: das reine und einfache Binärformat

DER (Distinguished Encoding Rules) ist das Binärkodierungsformat für die ASN.1-Strukturen, die ein X.509-Zertifikat beschreiben. Es handelt sich nicht um Text; wenn Sie es also mit einem Editor öffnen, sehen Sie anstelle der üblichen Base64-Zeichenkette Sonderzeichen.

Eine DER-Datei kann beliebige Zertifikate oder private Schlüssel enthalten und ist typischerweise an den Dateiendungen .der oder .cer erkennbar, insbesondere unter Windows oder auf Java-Plattformen. Unter Windows wird eine .der-Datei direkt als Zertifikatsdatei erkannt und per Doppelklick mit dem systemeigenen Zertifikatsbetrachter geöffnet.

Der praktische Unterschied zu PEM besteht darin, dass PEM-Dateien zwar einfach kopiert und per E-Mail versendet oder in Webformulare eingefügt werden können, DER-Dateien jedoch ein geschlossener Binärdatenblock sind , der für die direkte Verarbeitung durch Anwendungen vorgesehen ist. Intern sind die Informationen jedoch identisch: Eine PEM-Datei ist lediglich eine in Base64-Text umkodierte DER-Datei.

Tools wie OpenSSL ermöglichen es, mit einem einzigen Befehl zwischen DER und PEM zu wechseln, ohne den logischen Inhalt des Zertifikats zu verändern, sondern nur dessen Darstellungsform.

.cer- und .crt-Dateiendungen: Derselbe Hund mit einem anderen Halsband

Die Dateiendungen .cer und .crt werden verwendet, um Dateien zu kennzeichnen, die öffentliche Zertifikate enthalten , üblicherweise im PEM- oder DER-Format, abhängig vom System, auf dem sie generiert oder installiert werden.

In vielen Fällen handelt es sich bei einer .crt-Datei auf einem Apache-Server um ein PEM-Zertifikat, das von den Headern BEGIN und END CERTIFICATE umschlossen ist und direkt in einen Konfigurationsblock eingefügt werden kann. Unter Windows kann eine .cer-Datei entweder im PEM- oder im DER-Format vorliegen, wobei das Format je nach verwendetem Erstellungsprogramm üblicherweise irgendwo dazwischen liegt.

Wichtig ist zu verstehen, dass die Dateiendung das interne Format nicht eindeutig festlegt: Eine .cer-Datei kann im PEM-Text- oder DER-Binärformat vorliegen, und ein Zertifikatsanzeigeprogramm oder ein Hilfsprogramm wie OpenSSL bestimmt, wie sie gelesen wird. In Browsern und Windows-Systemen öffnet ein Doppelklick den Zertifikatsbetrachter , in dem Aussteller, Betreff, Gültigkeitsdatum, Schlüsselverwendung usw. angezeigt werden.

Wenn Sie ein Zertifikat ohne privaten Schlüssel aus einem Browser oder aus dem Windows-Zertifikatspeicher exportieren, erhalten Sie normalerweise eine .cer-Datei, die zur Überprüfung von Signaturen, Vertrauensketten oder zur Verschlüsselung von Informationen verwendet wird , jedoch niemals zum Signieren im Namen des Eigentümers (dazu benötigen Sie den privaten Schlüssel, der separat oder in einem geschützten Container gespeichert ist).

CSR-, KEY-, CA- und Zwischendateien: die übrigen Dateien, die dem Zertifikat beiliegen.

Bei der Verarbeitung eines SSL-Zertifikats oder eines persönlichen Zertifikats werden nicht nur .pfx-, .p12- oder .cer-Dateien verarbeitet. Der gesamte Prozess umfasst auch Dateien wie .csr, .key und die CA-Zertifikate (Root- und Zwischenzertifikat), die für die korrekte Funktion unerlässlich sind.

Die Zertifikatsignierungsanforderung ( CSR) (.csr) ist eine Datei, die Sie üblicherweise auf dem Server erstellen, auf dem das SSL-Zertifikat installiert wird. Sie enthält den öffentlichen Schlüssel, den Domänennamen, die Organisation, das Land und weitere Informationen, die die Zertifizierungsstelle zur Ausstellung des Zertifikats benötigt. Sie entspricht dem PKCS#10-Standard und ist in der Regel im PEM-Format kodiert, sodass Sie sie in das Formular des Anbieters kopieren und einfügen können.

Der private Schlüssel, auch KEY (.key) genannt , ist die Datei, in der der zum Zertifikat gehörende geheime Schlüssel gespeichert ist. Er liegt üblicherweise im PEM-Format vor und ist durch die Zeichenfolgen BEGIN PRIVATE KEY und END PRIVATE KEY begrenzt. Es handelt sich um eine äußerst sensible Datei, die nicht weitergegeben oder in öffentliche Repositories hochgeladen werden sollte und in vielen Fällen zusätzlich passwortgeschützt ist.

Die Zertifizierungsstellendatei (CA- Datei ) enthält den öffentlichen Schlüssel der ausstellenden oder zwischengeschalteten Stelle. Browser und Betriebssysteme verfügen über eine integrierte Liste vertrauenswürdiger Zertifizierungsstellen. Manchmal ist es jedoch erforderlich, Zwischenzertifikate zu installieren, um die Vertrauenskette zu vervollständigen und Clients die fehlerfreie Validierung des Serverzertifikats zu ermöglichen.

Diese Zwischenzertifikate können als PEM-Dateien (.pem, .crt, .cer) oder in einem Container wie .p7b bereitgestellt werden . Bei Hosting-Konfigurationen ist es üblich, für die korrekte SSL-Installation die CRT-Datei (Domainzertifikat), den KEY (privaten Schlüssel) und die CA- oder Zwischenzertifikatsdateien anzufordern.

PKCS#7 / P7B: Zertifikatskette ohne privaten Schlüssel

PKCS#7, typischerweise mit den Dateiendungen .p7b oder .p7c , ist ein Format zur Gruppierung eines oder mehrerer Zertifikate in einem strukturierten Container, ohne den privaten Schlüssel einzuschließen. Es wird häufig zur Verteilung von Zertifikatsketten (Serverzertifikat plus Zwischenzertifikate) in Windows- oder Java-Umgebungen (Tomcat, Keystore usw.) verwendet.

Eine .p7b-Datei ist typischerweise in Base64-ASCII kodiert, ähnlich einer PEM-Datei, und wurde ursprünglich in RFC 2315 als Teil der Standards für Public-Key-Kryptographie definiert. Heute ist ihr Nachfolger CMS (Cryptographic Message Syntax), aber die Bezeichnung PKCS#7 ist in der Welt der SSL-Zertifikate weiterhin weit verbreitet.

Dieses Format ist besonders nützlich, wenn Sie die gesamte Vertrauenskette auf einem Server oder einem System installieren müssen, das Zertifikate über einen Speicher verwaltet (z. B. den Java-Keystore). Normalerweise liefert ein SSL-Anbieter das Serverzertifikat separat von einer .p7b-Datei, die die gesamte CA-Kette enthält, oder eine einzelne .p7b-Datei mit allen Zertifikaten.

Wenn Sie eine .p7b-Datei in PEM konvertieren möchten, können Sie mit Tools wie OpenSSL die Zertifikate mit einem einzigen Befehl extrahieren und in einer oder mehreren Textdateien speichern. Anschließend können Sie die BEGIN/END CERTIFICATE-Blöcke trennen, falls Sie diese separat auf Ihren Server hochladen müssen.

Wichtig zu beachten ist, dass eine PKCS#7-Datei niemals den privaten Schlüssel enthält und daher allein nicht zum Signieren oder Entschlüsseln verwendet werden kann: Sie stellt lediglich den öffentlichen Teil der Zertifikatskette zur Verfügung, um das Vertrauen zu bestätigen.

PKCS#12: Was genau sind .pfx und .p12?

Der PKCS#12-Standard definiert einen passwortgeschützten Binärcontainer, der öffentliche Zertifikate, vollständige CA-Ketten und den zugehörigen privaten Schlüssel enthalten kann. Die gebräuchlichsten Dateiendungen für dieses Format sind .pfx und .p12, die praktisch gleichwertig sind.

Historisch gesehen war PKCS#12 ursprünglich ein Format, das eng mit Microsoft verbunden war, wurde aber im Laufe der Zeit in RFC 7292 standardisiert und wird heute in allen Arten von Systemen verwendet, gerade weil es die sichere Übertragung des Zertifikats- und privaten Schlüsselpaares von einem Computer zum anderen ermöglicht .

In der Windows-Welt wird beim Exportieren eines Zertifikats mit privatem Schlüssel aus dem Benutzer- oder Computerzertifikatspeicher vom Assistenten eine .pfx-Datei (oder .p12-Datei) generiert, die alles enthält, was zum Importieren in ein anderes System benötigt wird: privater Schlüssel, Zertifikatsinhaber und in der Regel die Zwischenzertifikatskette.

Beim Erstellen oder Exportieren einer PKCS#12-Datei werden Sie vom System zur Eingabe eines Passworts aufgefordert . Dieses Passwort wird später benötigt, um die Datei in einen anderen Browser, IIS, ein E-Mail-Programm oder sogar ein anderes Betriebssystem zu importieren. So kann niemand, der die .pfx-Datei stiehlt, sie ohne Kenntnis des Passworts verwenden.

Tools wie OpenSSL ermöglichen es Ihnen, eine .pfx- oder .p12-Datei in PEM zu konvertieren, sodass Sie eine Textdatei erhalten, in der Sie den privaten Schlüsselblock, das Serverzertifikat und die Zwischenzertifikate leicht finden und an der entsprechenden Stelle kopieren können (zum Beispiel in einem Hosting-Panel, das nur CRT, KEY und CA separat akzeptiert).

Erneuerung, Export und Import von .pfx- und .p12-Zertifikaten

Im Bereich der persönlichen Zertifikate (zum Beispiel solche, die von der FNMT oder anderen Behörden zur Identifizierung gegenüber der Verwaltung ausgestellt werden) ist die Art der Datensicherung und -erneuerung eng mit der Verwendung von .pfx- oder .p12-Dateien verbunden, die auf kryptografischen Karten, USB- Tokens oder direkt als geschützte Dateien auf dem Computer gespeichert werden.

Wenn Ihr persönliches Zertifikat noch nicht abgelaufen ist, bieten viele Behörden die Möglichkeit, es online zu verlängern : Die Verlängerung wird von der Registrierungsstelle (Berufsverband, Unternehmen, Zertifizierungsdienstleister usw.) aus aktiviert, und Sie erhalten per E-Mail einen Link, über den Sie den Vorgang von Ihrem eigenen Computer aus abschließen können.

Wenn das Zertifikat jedoch bereits abgelaufen ist, müssen Sie in der Regel persönlich mit Ihrer Kryptokarte oder dem Gerät, auf dem das abgelaufene Zertifikat gespeichert ist, zu derselben Registrierungsstelle gehen, sich ausweisen und eine neue Ausstellung beantragen, die Sie dann wieder im .pfx- oder .p12-Format exportieren und überall dort importieren können, wo Sie sie benötigen.

In Browsern wie Edge oder Chrome erfolgt der Import über den Windows-Zertifikatspeicher . In den Datenschutz- und Sicherheitseinstellungen können Sie den Zertifikatmanager öffnen, den Tab „Persönlich“ auswählen und eine .pfx- oder .p12-Datei importieren. Der Assistent fragt nach dem Containerpasswort und bietet an, den Schlüssel für zukünftige Backups als exportierbar zu markieren.

Wenn Sie anstelle einer .pfx-Datei eine .cer-Datei ohne privaten Schlüssel besitzen (Zertifikatsymbol ohne Schlüssel), kann diese Datei nur zur Installation des öffentlichen Zertifikats verwendet werden (sie wird unter „Andere Personen“ angezeigt), nicht aber zum Signieren oder Authentifizieren. In diesem Fall können Sie den privaten Schlüssel nicht wiederherstellen, und wenn Sie keine andere gültige Kopie besitzen, bleibt Ihnen nur die Möglichkeit, ein neues Zertifikat anzufordern.

Wie diese Formate in Server-SSL-Zertifikaten verwendet werden

Im täglichen Umgang mit Webservern, VPNs , Proxys oder Java-Anwendungen hängen die verwendeten Zertifikatsformate vom System und der Installationsart ab. Die Einrichtung von Apache unter Linux unterscheidet sich von der Einrichtung von IIS unter Windows oder Tomcat unter Java.

In Unix/Linux-Umgebungen (Apache, Nginx, HAProxy usw.) ist es üblich, mit separaten PEM-Dateien zu arbeiten : eine für den privaten Schlüssel (.key), eine weitere für das Serverzertifikat (.crt oder .cer) und gegebenenfalls eine dritte für die Zwischenzertifizierungsstellenkette. Alle diese Dateien werden in der Serverkonfiguration referenziert, um TLS einzurichten.

Auf Windows-Plattformen (IIS, Remotedesktopdienste usw.) wird häufig eine .pfx- oder .p12 -Datei mit Zertifikat, privatem Schlüssel und Schlüsselbund benötigt. Der Importassistent speichert die einzelnen Elemente automatisch im jeweiligen Speicher, sodass Sie sich keine Gedanken um die internen Details machen müssen.

In Java-Umgebungen (Tomcat, Anwendungen mit eigenem Keystore) werden JKS- oder PKCS#12- basierte Keystores verwendet . Je nach Tool und Java-Version wird häufig eine .pfx-Datei direkt importiert oder .p7b-Zertifikate werden verwendet, um die Vertrauenskette innerhalb eines Keystores zu konfigurieren.

Beim Kauf eines SSL-Zertifikats von einem Drittanbieter erhalten Sie möglicherweise verschiedene Dateikombinationen: eine CRT- und eine CA-Datei im PEM-Format, eine .p7b-Datei mit dem Schlüsselstring oder sogar eine vorbereitete .pfx-Datei. Der Schlüssel dient dazu, den Speicherort des privaten Schlüssels zu identifizieren (sofern dieser mit Ihnen bereitgestellt wird und nicht vom Server generiert wurde) und die Datei zu bestimmen, die das Serverzertifikat und den Zwischenschlüsselstring enthält.

In Hosting-Control-Panels werden Sie üblicherweise aufgefordert, Felder für CRT, KEY und optional das CA- oder Zwischenzertifikat auszufüllen. Falls Sie nur eine .pfx-Datei besitzen, können Sie diese mit OpenSSL in das PEM-Format konvertieren und anschließend die einzelnen Blöcke extrahieren, indem Sie diese sorgfältig vom Anfang bis zum Ende jedes Blocktyps kopieren.

Konvertierung zwischen Zertifikatsformaten mit OpenSSL

Sobald Sie wissen, was die einzelnen Dateien sind, ist der nächste logische Schritt, zu lernen, wie Sie diese konvertieren, wenn der Server oder die Anwendung ein anderes Format benötigt als das von Ihrem Internetanbieter oder Ihrer Zertifizierungsstelle bereitgestellte. Das Standardwerkzeug hierfür ist OpenSSL, das auf den meisten Linux-Distributionen verfügbar und auch unter Windows installierbar ist.

Wenn Sie beispielsweise ein Zertifikat im DER-Format (.der, .cer) besitzen und es in PEM konvertieren möchten, genügt ein einziger Befehl, der die Binärdatei in Base64 mit den entsprechenden Headern umwandelt. Umgekehrt können Sie ein PEM-Zertifikat in DER konvertieren, falls Ihr System nur Binärdateien akzeptiert.

Mithilfe einer PKCS#7-Datei (.p7b) können Sie mit OpenSSL Zertifikate im PEM-Format extrahieren. Ein einfacher Befehl gibt die enthaltenen Zertifikate aus und speichert sie in einer Textdatei. Anschließend können Sie die einzelnen BEGIN/END CERTIFICATE-Blöcke trennen, falls Sie separate Dateien benötigen.

Bei PKCS#12 (.pfx, .p12) ermöglicht OpenSSL die Konvertierung des Containers in eine PEM-Datei, die den privaten Schlüssel und alle Zertifikate enthält. Während des Vorgangs werden Sie nach dem Containerpasswort gefragt und können je nach Verwendungszweck wählen, ob der private Schlüssel verschlüsselt oder im Klartext in der PEM-Datei gespeichert werden soll.

Durch solche Konvertierungen sind Szenarien möglich, wie beispielsweise das Hochladen einer .pfx-Datei auf einen Linux-Server, deren Konvertierung in PEM und die anschließende Trennung der CRT- und KEY-Dateien zum Ausfüllen eines SSL-Installationsformulars, das PKCS#12-Container nicht direkt unterstützt.

Zusätzlich zu den direkten Konvertierungen DER↔PEM, PEM↔PKCS#7, PKCS#7↔PKCS#12 und PKCS#12↔PEM kann dasselbe Dienstprogramm CSRs generieren, Schlüssel verwalten, Zertifikate prüfen und Ablaufdaten kontrollieren, was es zu einem unverzichtbaren Werkzeug in jeder Umgebung macht, die mit Zertifikaten arbeitet.

Arten von digitalen Zertifikaten und Anwendungsbereiche

Neben dem Dateiformat ist es auch wichtig, den Zertifikatstyp anhand seines Verwendungszwecks oder der Art der Entität, die er repräsentiert, zu kennen, da dies Einfluss darauf hat, wie Kopien, Verlängerungen und Installationen verwaltet werden.

Auf europäischer Ebene (eIDAS-Verordnung) wird zwischen „einfachen“ elektronischen Zertifikaten und qualifizierten Zertifikaten unterschieden . Erstere erfüllen die grundlegenden Anforderungen an Identifizierung und Ausstellung, während qualifizierte Zertifikate strengere Identitätsprüfungsverfahren und anspruchsvollere technische und organisatorische Bedingungen seitens des Anbieters erfordern. Ein Beispiel hierfür in Spanien ist der elektronische Personalausweis (DNIe).

Betrachtet man den Inhaber, so lassen sich Zertifikate für natürliche Personen, juristische Personen oder juristische Personen ohne Rechtspersönlichkeit unterscheiden . Jedes Zertifikat dient der Unterzeichnung oder Authentifizierung in unterschiedlichen Kontexten: persönlichen Angelegenheiten, Transaktionen im Namen eines Unternehmens oder steuerlichen Verpflichtungen.

In der Welt der Webserver sind SSL/TLS-Zertifikate die bekannteste Zertifikatsfamilie . Sie werden auf Servern installiert, um die Kommunikation mit den Nutzern zu verschlüsseln. Innerhalb dieser Kategorie gibt es verschiedene Varianten wie Single-Domain-, Wildcard- und Multi-Domain-Zertifikate (SAN), die sich in der Anzahl der abgedeckten Domains und ihrem Validierungsgrad unterscheiden.

Unabhängig vom Typ können all diese Zertifikate letztendlich in den gleichen Formaten gespeichert und verteilt werden: .cer-, .crt-, .pem-, .p7b-Dateien oder .pfx/.p12-Container, abhängig vom System, auf dem sie verwendet werden, und der gewählten Methode zum Transportieren oder Sichern.

Der Nutzen digitaler Zertifikate ist enorm: Sie gewährleisten die Vertraulichkeit und Authentizität der Kommunikation, ermöglichen rechtsgültige elektronische Signaturen, vereinfachen administrative und kommerzielle Abläufe und ermöglichen es, dass zahlreiche Netzwerkdienste sicher funktionieren, ohne dass sich der Benutzer um kryptografische Details kümmern muss.

An dieser Stelle ist klar, dass Erweiterungen wie .pfx, .p12, .cer oder .crt lediglich unterschiedliche Arten sind, ein und dasselbe zu verpacken: ein X.509-Zertifikat, einen privaten Schlüssel und gegebenenfalls eine Vertrauenskette, die je nach Umgebung als Base64-Text, DER-Binärdatei oder PKCS-Container dargestellt werden, um die Installation und den Transport zwischen Systemen zu erleichtern.