Die aktuelle Liste der Länder mit Exportbeschränkungen finden Sie hier: swisssign.com/support/exportbeschraenkungen

Zwischenzertifikate auch Intermediate-Zertifikate genannt

Jedes SwissSign Endbenutzerzertifikat wird von einem SwissSign Zwischenzertifikat signiert. Das Zwischenzertifikat wiederum wird vom Rootzertifikat signiert. Damit ein Zertifikat vertrauensvoll erscheint, ist es wichtig, dass die komplette Zertifikatskette z.B. auf dem Webserver vorhanden ist. Die Betriebssysteme und Applikationen haben praktisch alle das Rootzertifikat mit dabei, das/die Zwischenzertifikat(e) muss aber installiert werden. Entweder wird das Endzertifikat auf swisssign.net (bisherige SwissSign CA) oder ra.swisssign.ch (neue SwissSign CA) mit der gesamten Zertifikatskette heruntergeladen, oder es wird das Zwischenzertifikat später nachträglich installiert. 

Rootzertifikate

Jedes SwissSign Endbenutzerzertifikat wird von einem SwissSign Zwischenzertifikat signiert. Das Zwischenzertifikat wiederum wird vom Rootzertifikat signiert. Damit ein Zertifikat vertrauensvoll erscheint, ist es wichtig, dass die komplette Zertifikatskette z.B. auf dem Webserver vorhanden ist. Die Betriebssysteme und Applikationen haben praktisch alle das Rootzertifikat mit dabei. Dennoch kann es für besondere Applikationen notwendig sein, Rootzertifikate zu installieren. Entweder wird das Endzertifikat auf swisssign.net oder ra.swisssign.ch mit der gesamten Zertifikatskette heruntergeladen, oder es wird das Rootzertifikat später nachträglich installiert. 

Das Rootzertifikat ist der Vertrauensanker einer PKI. Die Benutzung eines Rootzertifikats beinhaltet, dass die Benutzerinstanz alle Zertifikate akzeptiert, die von der betreffenden CA ausgegeben wurden.

Weitere Informationen über die CA-Nutzung, die Organisation, die Funktionen, Methoden und Prozesse sind dem SwissSign Certificate Policy CP und Certification Practice Statement (CPS) zu entnehmen: Repository

Sperrlisten

Gesperrte bzw. zurückgezogene Zertifikate werden in sogenannten Sperrlisten publiziert oder in einem Onlinedienst vorgehalten (OCSP), der online und aktuell die Gültigkeit eines Zertifikats beauskunftet.

Einer der gebräuchlichsten Validierungsdienste stellt die Überprüfung der Gültigkeit eines Zertifikats mittels einer sogenannten Zertifikatssperrliste (CRL) dar oder mittels OCSP (Online Certificate Status Protocol) dar.

Wie in der physischen Welt ist es auch in der digitalen Welt gefährlich, wenn man einen Schlüssel verliert oder der Schlüssel, z.B. aufgrund des Weggangs eines Mitarbeiters, keine Gültigkeit mehr hat. Daher werden immer wieder Schlüssel/Zertifikate gemeldet, die gesperrt werden müssen, um Schäden zu verhindern. SwissSign veröffentlicht – wie jede CA – diese Schlüssel/Zertifikate in sogenannten «Certificate Revocation Lists» (CRL).

Die CRL (Widerrufsliste oder Zertifikatssperrliste) enthält alle Seriennummern der Zertifikate, welche vor Ablauf ihrer Zertifikats-Lebensdauer für ungültig erklärt wurden. Bei der Zertifikatsstatusprüfung wird die Liste von einer öffentlichen URL geladen und die Seriennummer des Zertifikats, das geprüft werden soll, in dieser Liste gesucht: Ist es vorhanden, ist das Zertifikat gesperrt, andernfalls ist es gültig.

Revozierte bzw. für ungültig erklärte Zertifikate bleiben auch nach dem im Zertifikat angegeben Ablaufdatum auf der CRL. Grund dafür ist, dass es für die Validierung der Signatur wichtig ist zu wissen, wann ein Zertifikat revoziert wurde.

CRLs werden in der Regel in regelmässigen Abständen aktualisiert. Wie bei den Zertifikaten ist auch bei den CRL die Lebensdauer in der CRL selber festgelegt. Diese Lebensdauer ist massiv länger als die Ausstellungshäufigkeit (mindestens 2 mal pro Tag) vermuten lässt. Damit wird auch der «Fault majeur» abgedeckt. CRLs können lokal zwischengespeichert werden und ermöglichen die Offline-Abfrage eines Zertifikatsstatus. Dabei wird die Verbindung zwischen Zertifikatsinhaber und der Relying Party dem CSP nicht offengelegt. Allerdings gibt es eine relativ hohe Ungenauigkeit bei der Statusabfrage eines Zertifikats.

Eine Alternative bildet der online funktionierende Validierungsdienst OCSP (Online Certificate Status Protocol). Dieser gibt in Echtzeit Auskunft über die Gültigkeit eines Zertifikates. Für den OCSP Einsatz ist eine hohe Performance der CA wichtig. Die SwissSign CA stellt diese hohe Performance sicher und setzt auch für OCSP nur eigene, in der Schweiz entwickelte Software ein. Online-Statusprüfungen werden üblicherweise dort eingesetzt, wo die zeitgenaue Prüfung des Zertifikates wichtig ist – z.B. bei finanziellen Transfers.

Alle unseren Root-CA- und Intermediate-/Zwischen-CA-Zertifikate, sowie die ausgestellten Sperrlisten (CRLs) können unter dem folgenden Link https://www.swisssign.com/support/ca-prod.html heruntergeladen werden.

Gemäss CP/CPS muss die Sperrlistendatei für Zertifikate (CRL) mindestens alle 24 Stunden aktualisiert werden. In der Praxis aktualisiert SwissSign diese häufiger, nämlich auf Stundenbasis.

Grundsätzlich ist eine CRL-Datei zehn Tage gültig, daher enthält diese den Vermerk «Nächstes Update ...» (Erstellungsdatum+zehn Tage). Das ist bedingt durch die Regelung im Force-majeure-Fall: Hier sollte bei Ausfall der Systeme die Sperrlistendatei spätestens nach zehn Tagen wieder aktualisiert werden.

Mein Betriebssystem oder meine Anwendung zeigt mir Fehler an bzw. ich weiss nicht, wie ich das Zertifikat richtig installieren soll.

SwissSign trägt in den FAQs und Dokumentationen bekannte Probleme und deren Lösungen zusammen. Leider können wir keinen direkten Support hierzu leisten. Die Kernkompetenz der SwissSign AG ist die Erstellung standardisierter, vertrauenswürdiger Zertifikate. Da SwissSign weder Applikationen noch Betriebssysteme entwickelt, grenzt sich SwissSign vom Support von Applikationen und Betriebssystemen bewusst ab.

Vielleicht kann Ihnen aber einer unserer Partner bei seiner Applikation weiterhelfen: SwissSign Partner

Die Rootzertifikate von SwissSign werden in den am häufigsten genutzten Browsern installiert. Aktualisieren Sie Ihren Browser mit der neuesten Version und installieren Sie die neuesten Rootzertifikate von der Windows-Update-Seite. 

Informationen zur Kompatibilität und Verbreitung der SwissSign Rootzertifikate finden Sie hier: Kompatibilität | SwissSign

SwissSign erlaubt die Generierung eines eigenen Schlüsselpaares – privater und öffentlicher Schlüssel bei allen Angeboten. Die Mindestlänge des Schlüssels muss 2048 Bit sein.

Es ist zudem möglich, dass Ihr Webserver nicht die vollständige Zertifikatskette an Clients sendet. Dieses Problem lösen Sie mit der Funktion «SSLCertificateChainFile» in der Apache-Konfiguration.

Mit SwissSign SSL Zertifikaten erwerben Sie unlimitierte Serverlizenzen. Im Gegensatz zu den meisten anderen SSL Zertifikaten können Sie Ihr SwissSign SSL unbegrenzt nutzen.

Zertifikate samt privatem Schlüssel (.p12, PKCS#12)*

*Dieses Verfahren ist für SSL Zertifikate nicht anwendbar! 

.p12- oder PKCS#12-Formate enthalten ein öffentliches Zertifikat und den privaten Schlüssel (passwortgeschützt). Die Dateien .p12 oder PKCS#12 werden zum Beispiel zum Installieren in E-Mail-Programmen, Betriebssystemen und Webservern verwendet.

Bei Webservern ist die gesamte Zertifikatskette zu installieren. Die CA, die das Zertifikat ausgibt, vertraut typischerweise einer höher angesiedelten CA, die z.B. wiederum dem Rootzertifikat der SwissSign vertraut. Nur das Zertifikat der Root-CA der SwissSign ist bei allen Browsern anerkannt. Bitte laden Sie deshalb die Zertifikate der Zwischen-CAs auf der Download-Seite herunter und installieren Sie diese ebenfalls. Dies betrifft nur Personen, die einen Webserver installieren, und nicht Endnutzer.

Zertifikate ohne privaten Schlüssel

• .cer: DER- oder BASE64-codiert
• .crt: DER- oder BASE64-codiert
• .pem: Base64-kodiertes Zertifikat, umschlossen von «-----BEGIN CERTIFICATE-----» und «-----END CERTIFICATE-----»
• .p7b (Zertifikatskette): Zertifikate im Base64-kodierten ASCII-Format (z.B. für Windows OS, Java Tomcat)
• .p7c (Zertifikatskette): PKCS#7-signierte Datenstruktur ohne Dateninhalt, nur mit Zertifikat/en inklusive der gesamten Zertifikatskette (z.B. für Windows OS, Java Tomcat)
• .pem (Zertifikatskette): Base64-kodiertes Zertifikat inklusive kompletter Zertifikatskette (z.B. für Apache und ähnliche Plattformen)

Das Format .pfx ist deckungsgleich mit dem .p12-Format. Laden Sie das .p12-Format herunter und benennen Sie die Extension der Datei in .pfx um.

Wenn Sie das Passwort des privaten Schlüssels vergessen oder verlieren, kann SwissSign Ihnen leider nicht weiterhelfen. Das Passwort kann nicht wiederhergestellt oder zurückgesetzt werden. Es bleibt Ihnen leider nichts anderes übrig, als ein neues Zertifikat zu beantragen und das Passwort gut zu verwahren.

• Erstellen Sie auf dem Synology-System einen CSR – einen Zertifikatsantrag –, damit ist dann auch gleich das Schlüsselpaar auf dem Synology-Server erstellt.

• Nach der Ausstellung laden Sie von swisssign.net das Zertifikat im Format .pem herunter. Alle anderen Formate können Fehlermeldungen provozieren wie z.B.: «Die Dateikodierung muss als UTF-8 gespeichert werden.»

• Laden Sie zudem das Zwischenzertifikat (Typ G22) von der Downloadseite herunter.

• Nun können Sie auf dem Synology-Server die Dateien «privater Schlüssel» (lokal erzeugt) sowie das Zertifikat im .pem-Format und das Zwischenzertifikat im .perm-Format laden.

Dies kann grundsätzlich zwei Ursachen haben:

• Beim Aufsetzen einer SSL-Verschlüsselung oder auch in E-Mail-Systemen ist vergessen worden, ein Zwischenzertifikat zu installieren. Siehe FAQ «Mein Zertifikat läuft auf meinem Betriebssystem oder Browser nicht, obwohl SwissSign diese unterstützt».

• Der Kunde betreibt in seinem Proxy eine sogenannte «SSL Inspection». Diese Funktionalität bricht die verschlüsselte Verbindung auf und prüft die Kommunikation auf nicht zugelassene Inhalte oder sogar Malware beim Download. SSL Inspection arbeitet in der Regel mit nicht vertrauenswürdigen, eigenen Zertifikaten. Somit sind nicht nur Seiten mit SwissSign Zertifikaten, sondern auch andere Seiten betroffen. Abhilfe schafft das Herauskonfigurieren der betreffenden Seite im Proxy.

Häufig basieren diese Probleme nicht auf fehlenden oder fehlerhaften Root-Zertifikaten in den Betriebssystemen oder Browsern, sondern es wurde beim Aufsetzen einer SSL-Verschlüsselung oder auch in E-Mail-Systemen vergessen, ein Zwischenzertifikat zu installieren.

Zertifikate sind hierarchisch angeordnet: Das Zertifikat selber vertraut einem Zwischenzertifikat, ggfs. vertraut dieses einem weiteren Zwischenzertifikat usw. Schliesslich vertrauen die Zwischenzertifikate auch wieder den Root-Zertifikaten, die in den Browsern und Betriebssystemen gelistet sind. Da die Browser und Betriebssysteme nur die Root-Zertifikate enthalten, ist die Vertrauenskette ohne Zwischenzertifikate unterbrochen.

Im Windows-Umfeld kommen diese Probleme seltener vor, da Microsoft Windows bzw. die Windows-Browser versuchen, Zwischenzertifikate zwischen zu speichern, sobald eine Seite z.B. mit korrekter Installation eines SwissSign Zertifikates einmal aufgerufen wurde. Diese Zwischenspeicherung wird dann automatisch herangezogen, wenn das Zwischenzertifikat nicht korrekt installiert wurde, und der «Fehler» fällt dem Anwender gar nicht auf.

Bei Linux hingegen fällt die fehlende Konfiguration sofort auf. Abhilfe schaffen der Download der gesamten Zertifikatskette und die Installation der Zertifikatskette inklusive Zwischenzertifikaten:

Anleitung für bisherige CA (swisssign.net):

• Öffnen Sie hierzu den Link, den Sie bei der Zertifikatsausstellung erhalten haben, um die Zertifikate herunterzuladen. Alternativ können Sie auch Ihr Zertifikat auf swisssign.net suchen und dann die Schaltfläche «Herunterladen» betätigen.
• In den angebotenen Downloadformaten wählen Sie die Datei mit der Endung .p7c oder .pem (ganze Zertifikatskette). Alle anderen Downloads – auch die .p12-Datei – enthalten keine Zwischenzertifikate.

Anleitung für neue CA (ra.swisssign.ch):

• Öffnen Sie hierzu den Link, den Sie bei der Zertifikatsausstellung erhalten haben, um die Zertifikate herunterzuladen. Alternativ können Sie auch Ihr Zertifikat auf ra.swisssign.ch, Menü «Bestellungen und Zertifikate» suchen.
• Sieh haben dann die Möglihchkeit, das Zertifikat herunterzuladen:
  • Im PEM- bzw. base64-Format
  • Direkt im DER-Format
  • Als Zertifikatskette (PKCS#7-Format)

Bevor ein SSL Zertifikat ausgestellt werden kann, muss ein Schlüsselpaar und eine technische Zertifikatsanforderung – ein Certificate Signing Request (CSR) – erstellt werden. Die CSR-Datei muss aus regulatorischen Gründen kundenseitig erstellt werden. Beispiele für Software zur CSR-Erstellung sind:

• Download < https://www.openssl.org/source/>
• Bedienungsanleitung < https://www.openssl.org/docs/man3.0/man7/crypto.html>
• (Java) KeyStore Explorer

Für die Umformatierung gibt es verschiedene Werkzeuge. Z.B. erlaubt der Windows-Zertifikats-Viewer die Speicherung eines Zertifikats in den folgenden Formaten:

• Direkt im binären Format (DER – «Distinguished Encoding Rules)
• Als Text-Datei codiertes Format (Base64 bzw. PEM – «Privacy Enhanced Mail»)
• Im PKCS#7-Format (p7b bzw. CMS – «Cryptographic Message Syntax)

In der elektronischen Welt erhält der Begriff Vertrauenswürdigkeit eine neue Dimension. Benutzer müssen in der Lage sein, den Kommunikationspartner eindeutig zu identifizieren.

Ein digitales oder elektronisches Zertifikat (Certificate) ist eine elektronische Bescheinigung, die einen Signaturprüfschlüssel mit dem Namen einer Person, Organisation oder eines Servers verknüpft. Oder anders: Bei einem Zertifikat handelt es sich um eine nicht veränderbare «elektronischen Identitätskarte», die der Benutzer für die Identifikation und/oder Verschlüsselung im Internet verwenden kann.

Identifikation: Zertifikate werden verwendet,

•  um den Sender von Informationen zu identifizieren.
•  um den Server, mit dem sich ein User verbindet, zu identifizieren.
•  um den User, der sich mit einem Server verbindet, zu identifizieren.

Verschlüsselung: Digitale Zertifikate enthalten den öffentlichen Schlüssel des Zertifikats-Inhabers. Dieser kann von seinem Gegenüber benutzt werden, um eine E-Mail oder ein Dokument zu verschlüsseln, das über das Internet versendet wird.

Zertifikate spielen auch eine wichtige Rolle bei sicheren Web-Transaktionen wie https (SSL Zertifikate).

Es gibt verschiedene Typen von digitalen Zertifikaten. Das minimale Set enthält Folgendes:

• Den öffentlichen Schlüssel des Zertifikatsinhabers (Person, Computer/Maschine oder Organisation)

• Informationen zum Zertifikatsinhaber

• Information zum Herausgeber des Zertifikats, also zur CA oder zur Organisation, die das Zertifikat ausgeliefert hat.

• Digitale Signatur dieses Zertifikats durch den Herausgeber

• Auslieferungs- und Auslaufdatum des Zertifikats

• Seriennummer des Zertifikats

• Zertifikate von SwissSign enthalten noch Angaben zur CP und CPS.

Der Gebrauch von Zertifikaten garantiert Ihnen Sicherheit, Datenschutz und Vertrauen. Zertifikate werden bei verschiedenen Anwendungen eingesetzt. Zum Beispiel bei Secure E-Mail, E-Business, E-Government, E-Health usw. 

Auf der Webseite zu unseren Partner-Lösungen erfahren Sie mehr.

Das Public Key Verfahren ist ein asymmetrisches, kryptographisches Verfahren, bei dem ein Schlüsselpaar zum Einsatz kommt. Dieses kryptographisches Schlüsselpaar besteht aus einem öffentlichen und einem privaten Schlüssel. Daten, die mit einem dieser Schlüssel verschlüsselt wurden, können nur mit dem anderen Schlüssel wieder entschlüsselt werden. Diese kryptographische Methode kann nun sowohl für Verschlüsselung als auch für technische Signaturen genutzt werden.

Im Falle der Verschlüsselung werden die Daten für den Empfänger mit dem öffentlichen Schlüssel (Public Key, Schlüssel im Zertifikat) verschlüsselt, und können nun nur noch durch den entsprechenden privaten Schlüssel entschlüsselt werden.

Im Falle der technischen Signatur werden die Daten für den Empfänger durch den privaten Schlüssel des Senders verschlüsselt und können dann durch den Empfänger mit Hilfe des öffentlichen Schlüssels geprüft werden.

Der öffentliche Schlüssel/Public Key ist öffentlich über das Zertifikat zugänglich. Dieser Schlüssel wird zur Verschlüsselung von Daten oder zur Bestätigung der digitalen Signatur des Unterzeichners (Identifikation) verwendet. Mit dem öffentlichen Schlüssel verschlüsselte Daten können nur mit dem zugehörigen privaten Schlüssel entschlüsselt werden.

Der private Schlüssel/Private Key ist nur dem Zertifikatsinhaber bekannt bzw. darf nur ihm zugänglich sein. Er wird für die Entschlüsselung von Daten und zur Erstellung einer digitalen Signatur verwendet.

Das Zertifikat enthält einen Eintrag «Key Usage». Dieses Feld definiert die Verwendung für das Zertifikat. Mögliche Einträge für die Key Usage sind: Digitale Signatur, Non-Repudiation/Content-Commitment (Nicht-Abstreitbarkeit bzw. Verpflichtung auf den Inhalt), Key Agreement (Schlüsselvereinbarung), Verschlüsselung und/oder Datenverschlüsselung.

Jedes digitale Zertifikat durchläuft den folgenden Lebenszyklus:

• Zertifikats-Antrag: Ein Benutzer beantragt ein Zertifikat.

• Antrags-Prüfung: Die Registration Authority (RA) prüft die Identität des Benutzers/Antragstellers.

• Generierung/Ausstellung der Zertifikate: Die Certificate Authority (CA) stellt das Zertifikat aus. Dieses Zertifikat enthält Angaben zum Inhaber, zum Herausgeber, der erlaubten Nutzung und dessen Lebensdauer (gültig von und gültig bis)

• Revokation/Ungültigkeit: Das Zertifikat wird vor dem Verfall revoziert bzw. für ungültig erklärt.

• Zertifikats-Laufzeitende: Die Lebensdauer des Zertifikats ist abgelaufen.

• Zertifikats-Renewal bzw. «Rekey»: Erneuerung des Zertifikats.

Vertrauen ist das grundlegende Prinzip in jedem Sicherheits-Modell. Dies ist auch bei der Public Key Infrastruktur (PKI) der Fall. Um mit Zertifikaten überhaupt arbeiten zu können, müssen Sie der CA, die das Zertifikat ausgestellt hat, vertrauen.

PKIs sind immer hierarchisch organisiert. Die oberste Ebene der Hierarchie (Root) muss ausdrücklich als vertrauenswürdig hinterlegt sein, so dass dem Inhalt des entsprechenden Root-Zertifikats (Stammzertifikate) vertraut wird.

Die SwissSign Root-Zertifikate sind als vertrauenswürdig anerkannt, d.h. sie sind in u.a. folgenden Root Trust Stores hinterlegt: Microsoft, Mozilla (NSS) und Apple OS X. Anbei sehen Sie die Verbreitung der SwissSign Root-Zertifikate.

Dem Endnutzer dieser Anwendungen werden deshalb die SwissSign Zertifikate als vertrauenswürdig angezeigt. Sobald also das Root-Zertifikat einer PKI als vertrauenswürdig hinterlegt ist, kann jedes Unter-Zertifikat dieses hierarchischen Stammes sicher überprüft werden.

Einer CA wie SwissSign zu vertrauen bedeutet zudem, den verschiedenen zur PKI gehörigen Prozessen zu vertrauen, wie etwa der Benutzerregistrierung oder der Zertifikatsvalidierung (CRL, OCSP). Die Certificate Policy und Certification Practice Statements (CP/CPS) bringen dabei Transparenz in die Prozesse und helfen das Vertrauen zu stützen. So bestimmen Sie Ihr Vertrauen in die SwissSign CA, indem Sie die entsprechenden CP/CPS lesen. SwissSign ist zudem eine nach Schweizer Recht qualifizierter Zertifizierungsdienstanbieter (CSP), welcher die Anforderungen des Schweizerischen Bundesgesetzes über die elektronische Signatur (ZertES) erfüllt. Das ZertES seinerseits entspricht den strengsten internationalen Standards auf diesem Gebiet.

Importieren Sie schliesslich auch die entsprechenden SwissSign Root-Zertifikate in Ihre Programme, um das Vertrauensverhältnis aufzusetzen.

Eine Public Key Infrastructure (PKI) ist eine Infrastruktur bzw. eine Umgebung, in der verschiedene Anwendungen und Funktionen mit kryptographischen Schlüsseln (öffentliche und private Schlüssel) und Zertifikaten ausgeführt werden. Diese Anwendungen reichen von Zugangskontrollen und sicheren E-Mail-Anwendungen bis hin zu verschiedenen Arten von digital signierten Informationen im Zusammenhang mit der CA oder RA.

Eine Certificate Authority (CA) ist eine Anbieterin von Zertifizierungsdiensten oder eine Zertifizierungsstelle – eine «Trusted Third Party». Teils ist auch von einem Zertifizierungsdienstanbieter/Certification Service Provider (CSP) die Rede.

SwissSign ist eine CA – eine Stelle, die im Rahmen einer elektronischen Umgebung Daten von Personen, Organisationen oder Maschinen bestätigt und zu diesem Zweck digitale Zertifikate ausstellt.

Eine Registration Authority/Registrierungsstelle (RA) ist ein Dienst von SwissSign, der darin besteht, die Identität und wenn nötig die Attribute jedes Antragstellers eines Zertifikats zu überprüfen, bevor die CA das entsprechende Zertifikat erzeugt oder die Daten zur Aktivierung der Nutzung des Signaturschlüssels zuweist.

Die Zertifizierungspolitik/Certificate Policy (CP) ist ein Dokument des Zertifizierungsdienstanbieters (CSP), das die für einen Zertifikatstyp geltenden Regeln beschreibt («Was soll erreicht werden»). Es umfasst die Gesamtheit von Regeln, welche die Anwendbarkeit eines Zertifikats für einen bestimmten Personenkreis und/oder eine Klasse spezieller Anwendungen mit gemeinsamen Sicherheitsanforderungen vorschreiben. Es dient Dritten zur Analyse der Vertrauenswürdigkeit.

Das CPS macht Aussagen über die Zertifizierungspraxis, d.h. wie die Anforderungen umgesetzt werden.

CP und CPS bilden die rechtliche Basis für die Beziehung zwischen den Zertifikatsinhabern und SwissSign.

Sie finden diese Dokumente im SwissSign Repository.

Hersteller von Browsern, Betriebssystemen, Mailclients und anderen Softwares, die Zertifikate auswerten, müssen ein Programm pflegen, in dem sie die CSPs verwalten, die sie ihren Kunden als vertrauenswürdige CSPs empfehlen (Rootstore Programm).

Die Pflege eines eigenen Rootstore Programmes ist aufwendig. Es umfasst die Pflege der Anforderungsdokumente und der aufgenommen CSPs. Das Pflegen der minimalen Anforderungsdokumente übernimmt deshalb das CA Browser Forum. In diesem Gremium sind die Rootstore Progamm-Pfleger (Software Hersteller) und die CSPs vertreten und erarbeiten und pflegen gemeinsam die Anforderungsdokumente.

Heute basieren immer mehr Rootstore Programme auf den «Baseline Requirements» des CA Browser Forums. www.cabforum.org

Über das «Certificate Transparency» (CT) -Sicherheitsverfahren sollen fehlerhaft arbeitende Zertifizierungsstellen identifiziert und aus der abgesicherten Internetkommunikation ausgeschlossen werden. Das von Google Chrome vorangetriebene Verfahren ist ein wichtiger Eckpfeiler der vertrauenswürdigen Internetkommunikation.

Grundidee: In einem kryptografisch geschützten Log-System sollen alle für die sichere Internet-kommunikation genutzten Zertifikate registriert und von mindestens 3 weltweit verteilten, zentralen Log-Servern verwaltet werden. Nachträgliche Veränderungen, Auffällige und unzulässige Registrierungen, falsche Zertifikate, Ergänzungen oder sonstige Manipulationen eines einmal registrierten Zertifikats wären damit ausgeschlossen bzw. würden von jedem Browser umgehend erkannt.

SwissSign unterstützt mit ihren SSL-Zertifikaten vollumfänglich Certificate Transparency.

In der entsprechenden CP/CPS des Herausgebers können Sie nachlesen, mit welcher Qualität der Zertifikatsinhaber (Absender) durch den Herausgeber identifiziert wurde. So ist die Authentizität des Absenders durch eine gültige und vertrauenswürdige Signatur gegeben. Gesundes Misstrauen ist aber trotzdem angezeigt bei unbekannten Absendern, besonders wenn der Herausgeber der Signatur ebenfalls nicht bekannt ist.

E-Mails werden mit dem Public Key (öffentlicher Schlüssel) des Empfängers verschlüsselt und dem Private Key (privater Schlüssel) des Empfängers entschlüsselt. Signiert wird mit dem Zertifikat.

• Zertifikate bzw. das Passwort zum privaten Schlüssel können verlorengehen. Die mit diesem Zertifikat verschlüsselten E-Mails können nie mehr und durch niemanden mehr gelesen werden.

• Zertifikate werden erneuert, aber es wird vergessen, das abgelaufene alte Zertifikat ebenfalls noch zu installieren. Alle alten aufbewahrten E-Mails können nicht mehr gelesen werden. Zugriff nach Zertifikats-Ablauf

• Ein Mitarbeitender verlässt die Firma oder ist längere Zeit abwesend. Seine E-Mails können durch keinen anderen mehr gelesen werden.

• Ein Virus oder Trojaner wird mit einer verschlüsselten E-Mail zugesendet. Kein Virenschutzprogramm kann eine verschlüsselte E-Mail durchsuchen, der Virus oder Trojaner kann ungestraft eindringen. Somit kann Verschlüsselung in diesem Falle sogar ein Sicherheitsrisiko bedeuten.

Das SSL Zertifikat mit seinen asymmetrischen Schlüsseln wird nur für die eindeutige und sichere Identifikation des Servers, für die gegenseitige Authentisierung verwendet. Bei Legacy-Anwendungen wird das Zertifikat auch für Verschlüsselung verwendet.

Die Zertifikatsausstellung richtet sich nach der Norm RFC 5280. Die neuere Norm sieht den Eintrag im Subject Distinguished Name vor als auch im Subject Alternative Name (SAN). Insbesondere auf letzteres achten die meisten Mailapplikationen am Markt. Die Platzierung der E-Mail-Adresse im emailAddress Attribut des Subject distinguished Name ist veraltet und wird von SwissSign nicht mehr genutzt.

RFC steht für «Request for Comments». RFCs sind eine Reihe technischer und organisatorischer Dokumente des RFC-Editors, die allgemein und international als Internet Standards akzeptiert werden. Das RFC System wurde bereits 1969 initiiert.

Mehr Informationen siehe www.rfc-editor.org.

Certification Authority Authorization (CAA) ist ein 2013 publizierter Internetstandard mit der Bezeichnung RFC 6844.

Domänennamen sind ähnlich einem grossen Telefonbuch in einem weltweit verteilten Register mit Namen aufgeführt, dem sogenannten Domain Name Service oder kurz DNS. Eine Webseite mit einem klingenden Namen, wie www.swisssign.com wird durch diesen Dienst in eine Internetadresse, wie z.B. «46.175.9.80» umgesetzt und so für verschiedene Internetdienste, beispielsweise einem Browser erreichbar. Der Domain Name Service erlaubt neben der Umsetzung verschiedene Zusatzinformationen, wie Namen und Adresse des Eigentümers einer Webseite.

Durch den Standard CAA werden nun weitere Informationen für diese Domänen gespeichert: Es wird festgehalten, welche Zertifizierungsstelle für die genannte Domäne ein Zertifikat ausstellen darf. Ist keine Zertifizierungsstelle eingetragen, kann jede ein Zertifikat ausstellen, anderweitig darf eine Zertifizierungsstelle kein Zertifikat für die Domäne ausstellen, sofern ihr Name dort nicht genannt wurde.

CAA ist ein Verfahren, bei dem der Domäneneigentümer festlegen kann, welche CA für seine Domäne Zertifikate ausstellen darf.  Hierzu wird im DNS ein sogenannter CAA record eingetragen. SwissSign überprüft ab September 2017 alle Domänen vor Zertifikatsausstellung darauf, ob Sie eine Einschränkung in ihrem CAA record haben. Domänen, die eingeschränkt wurden, Zertifikate von Zertifizierungsstellen anzunehmen, die nicht SwissSign heissen, werden im Zertifikat nicht zugelassen. Der Zertifikatsantrag wird abgelehnt. Sofern keine Einschränkung platziert wurde oder der CAA record SwissSign zulässt, wird das Zertifikat genehmigt.

Der CAA Konfigurator hilft Ihnen, die exakte Einstellung für Ihre Webseite zu finden.

Anbei einige Beispiele abhängig von der eingesetzten DNS Technologie:

Erlaubnis für SwissSign Zertifikate auszustellen

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com"

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

Erlaubnis für SwissSign Nicht-Wildcard Zertifikate auszustellen

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue "swisssign.com"

example.com.     IN       CAA      0 issuewild ";"

 Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 20 0005697373756573776973737369676E2E636F6D

example.com.     IN       TYPE257  \# 12 0009697373756577696C643B

Erlaubnis für SwissSign Nur Wildcard Zertifikate auszustellen

Standard BIND Zone File

For BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0

example.com.     IN       CAA      0 issue ";"

example.com.     IN       CAA      0 issuewild "swisssign.com"

Legacy Zone File (RFC 3597 Syntax)

For BIND <9.9.6, NSD <4.0.1

example.com.     IN       TYPE257  \# 8 000569737375653B

example.com.     IN       TYPE257  \# 24 0009697373756577696C6473776973737369676E2E636F6D

Leider Nein, da Sie gemäss www.whois.ch nicht Besitzer der Domäne dyndns.ch oder dyndns.org sind und DynDNS keine Domainvalidierung vornimmt, wird es schwierig, eine Bestätigung des Besitzers zu erhalten, welche auch überprüfbar ist.

Ja dies ist möglich. Um ein SSL Gold EV Zertifikat zu erwerben, müssen auch Vereine eine Registernummer angeben.

In der Schweiz können Vereine wie Unternehmen eine Unternehmens-ID (UID) beantragen. Diese ist nicht zu verwechseln mit der EU-Umsatzsteuer-ID (EU-UID). Vereine mit einem Jahresumsatz unter CHF 150'000 sind zwar befreit von der Mehrwertsteuer, erhalten auf Anfrage aber eine Unternehmens-ID. Diese UID ist als Registernummer in das Zertifikat einzutragen.

Deutsche Vereine sind als eingetragene Vereine im Vereinsregister eingetragen und können diese Nummer verwenden.

SwissSign kann die Schweizer UID einsehen. Sofern Sie die Sichtbarkeit Ihrer UID nicht eingeschränkt haben, reichen Ihre Vereinsangaben aus. Andernfalls geben Sie uns bitte eine UID Bestätigung mit. Ausländische Vereine legen bitte einen Registerauszug zur Bestätigung bei.

Die Unternehmens-Identifikationsnummer (UID) ersetzt die bisherige Firmennummer im Handelsregister.

Das Bundesamt für Statistik (BFS) ordnet jedem in der Schweiz wirtschaftlich aktiven Unternehmen, eine eindeutige und übergreifende Unternehmens-Identifikationsnummer (UID) zu. Diese ermöglicht es den Unternehmen, sich bei allen Behördenkontakten mit ein und derselben Nummer zu identifizieren.

In den SwissSign SSL Gold EV Zertifikaten wird seit diesem Zeitpunkt auf die UID referenziert.

SSL Zertifikate gibt es grundsätzlich in drei Ausprägungen:

• Single-Domain: Nutzbar nur für eine spezifische Webseite. Beispiel: mywebsite.com.
• Multi-Domain: Nutzbar für mehrere Webseiten/Domänen. Beispiel: mywebsite.com, yourwebsite.com, hiswebsite.ch.
• Wildcard: Nutzbar für jede Webseite mit einem festgelegten Domänennamen. Beispiel: db.mywebsite.com, mail.mywebsite.com, sap.mywebsite.com etc.

Multi-Domain Zertifikate werden auch oft UCC/SAN (Unified Communication Certificates/Subject Alternative Name) genannt, da sie prädestiniert sind für den Einsatz bei Exchange in einer Microsoft Umgebung. Im SAN Feld des Zertifikates befindet sich bei den Multi-Domain und Wildcard Zertifikaten ein Eintrag, welcher auf die weiteren Domänen oder auf das Wildcard hinweist.

Sehr häufig werden Multi-Domain oder Wildcard Zertifikate auch wegen ihres Preisvorteils verwendet. Kopien des gleichen SwissSign Zertifikates können beliebig auf verschiedenen Servern eingesetzt werden. So kann ggfs. mit einem Wildcard Zertifikat eine komplette Firmenumgebung abgesichert werden. Die Möglichkeiten mit einem Wildcard Zertifikat sind auf der einen Seite sehr bequem, können auf der anderen Seite aber in grossen Firmenstrukturen auch riskant sein: Sollte ein privater Schlüssel dieses Zertifikates auf einem der vielen Server kompromittiert werden und damit eine betrügerische Webseite mit ihrem Domänennamen als Man-in-the-Middle geschaltet werden, fällt das kaum auf und der Schaden ist gross. Zumal diese betrügerische Seite perfekt mit einem Zertifikat des Unternehmens geschützt ist. Daher dürfen Wildcard Zertifikate auch nicht mit dem EV Standard angeboten werden.

Multi-Domain Zertifikate haben dieses Problem nicht.

Mit den vielen SAN Einträgen steigt aber die Gefahr, dass das Multi-Domain Zertifikat vorzeitig ausgetauscht werden muss: Häufig befinden sich unter den Domänen auch solche, die einem selber nicht gehören und für die bei Ausstellung eine Vollmacht ausgestellt werden musste. Fällt eine Domäne weg, dann wird das Zertifikat ungültig und sämtliche eingesetzte Multi-Domain Zertifikate müssen ausgetauscht werden.

Wie bei jeder Entscheidung müssen Nutzen, Gefahren und Risiken abgewogen werden. In kleinen überschaubaren Umgebungen oder für den Einsatz in Microsoft UCC Umgebungen gibt es sicherlich gute Gründe für einen Einsatz dieser Zertifikate. Beachten Sie speziell zum Einsatz auf einer Microsoft Exchange Umgebung auch unseren gesonderten FAQ «UCC/SAN – Wildcard oder Multi-Domain für Microsoft Exchange?»

Nein, das ist gemäss RFC 2818 nicht erlaubt.

Wir empfehlen daher den Kauf von zwei SSL Wildcard Zertifikaten: eines für *.mydomain.com und eines für *.sub2.mydomain.com. Es ist bei SwissSign SSL Wildcard Zertifikaten auch nicht möglich, unterschiedliche Alternative Names (SAN) anzugeben.

Die alte CA-Plattform bietet die Möglichkeit, neben der Wildcard-Domain (z.B. «*.swisssign.com») auch die «Base Domain» (z.B. «swisssign.com») aufzunehmen. Die neue CA-Plattform bietet diese Möglichkeit auch, gehen Sie dazu während eines Beantragungs-Vorgangs für ein Wildcard-Zertifikate wie folgt vor:

• Klicken Sie unter dem Absatz «DNS» den Button «+Element hinzufügen»
• Geben Sie im Feld «DNS1*» den Wildcard-Eintrag ein, also z.B. «*.swisssign.com»
• Geben Sie im Feld «DNS2*» den Base-Domain-Eintrag ein, also z.B. «swisssign.com»
• Fahren Sie wie üblich mit dem Ausstellungsprozess fort.

Grundsätzlich ist der Erwerb eines E-Mail-Zertifikates für einen Team Account möglich. Allerdings ist das weiterhin ein persönliches Zertifikat und verlangt einen Schlüsselverantwortlichen.

Es gelten hier die Regelungen der CP und der CPS. Diese sehen Folgendes vor:

• Wurde das Zertifikat als Gold Zertifikat erworben, so ist hierfür anstelle des Vornamens und Namens die Bezeichnung «pseudo:» zu verwenden (Pseudonym-Zertifikat). Beispiel: pseudo: Sales Team

• Bei Silver Zertifikaten, die nur E-mail-validiert sind, kann jede E-Mail-Adresse zertifiziert werden, sofern überprüft wurde, dass diese E-Mail-Adresse existiert.

Die Verschlüsselung des E-Mails findet mit Hilfe des Empfänger-Zertifikats statt. Daher ist es notwendig, dass der Sender das Zertifikat des Empfängers erhält. Dies kann manuell geschehen oder in dem ein entsprechender Secure Mail Gateway, die Zertifikate aus eingehenden E-Mails sammelt.

E-Mails werden mit dem Public Key (öffentlicher Schlüssel) des Empfängers verschlüsselt und dem Private Key (privater Schlüssel) des Empfängers entschlüsselt. Signiert wird mit dem Zertifikat.

• Zertifikate bzw. das Passwort zum privaten Schlüssel können verlorengehen. Die mit diesem Zertifikat verschlüsselten E-Mails können nie mehr und durch niemanden mehr gelesen werden.

• Zertifikate werden erneuert, aber es wird vergessen, das abgelaufene alte Zertifikat ebenfalls noch zu installieren. Alle alten aufbewahrten E-Mails können nicht mehr gelesen werden. Zugriff nach Zertifikats-Ablauf

• Ein Mitarbeitender verlässt die Firma oder ist längere Zeit abwesend. Seine E-Mails können durch keinen anderen mehr gelesen werden.

• Ein Virus oder Trojaner wird mit einer verschlüsselten E-Mail zugesendet. Kein Virenschutzprogramm kann eine verschlüsselte E-Mail durchsuchen, der Virus oder Trojaner kann ungestraft eindringen. Somit kann Verschlüsselung in diesem Falle sogar ein Sicherheitsrisiko bedeuten.

Die digitale Signatur einer signierten E-Mail wird als Anlage gesendet. Diese Anlage wird vom E-Mail-Programm des Empfängers automatisch geprüft. Bei den meisten Webmail-Providern wie z.B. Gmail oder Hotmail wird die Signatur allerdings nur als Anlage mit dem Dateinamen smime.p7s angezeigt, ohne dass eine Signaturprüfung durchgeführt wird.

Der E-Mail-Client stuft den Aussteller des Zertifikates als nicht vertrauenswürdig ein. Dies kann behoben werden, indem man den Aussteller als vertrauenswürdig bezeichnet. Üblicherweise übernehmen die Hersteller dieser Programme diese Aufgabe mittels ihrer Root-Store-Programme.

Indem Sie den Herausgeber SwissSign als vertrauenswürdige Root eintragen. Das heisst, Sie beantworten die Frage «Wollen Sie dem Herausgeber vertrauen?» mit Ja. Wenn Sie einen Firmen-PC nutzen, bitten wir Sie, sich an Ihren IT-Support zu wenden.

Sehr häufig benötigen unsere Kunden ein Zertifikat, um sich auf einer Webseite zu authentisieren (anzumelden).

Für so eine TLS-WWW-Client-Authentisierung ist das Zertifikat Pro S/MIME E-Mail ID Gold mit Authentisierung vorgesehen. Es kann zudem auch zur E-Mail-Verschlüsselung und -signierung genutzt werden.

Für den Zugang zu Ihrer MPKI muss Ihre SwissID auf ein höheres Vertrauensniveau gehoben werden. Wie das geht, erfahren Sie unter dem folgenden Link, der Ihnen Schritt-für-Schritt hilft, Ihre Identität zu verifizieren:

https://www.swisssign.com/support/dokumentationen/ra-operator-onboarding.html

Das Anlegen eines SwissID Kontos braucht nur wenige Minuten. Wichtig ist, dass Sie dabei als MPKI Operator immer die E-Mail-Adresse nutzen, die in der MPKI Bestellung im Abschnitt «RA Operatoren» hinterlegt wurde. Danach folgen Sie bitte der Schritt-für-Schritt Anleitung unter folgendem Link:

https://www.swisssign.com/support/dokumentationen/ra-operator-onboarding.html

Wenn Sie sich als MPKI Operator plötzlich nicht mehr auf Ihrer MPKI einloggen können, kann das damit zusammenhängen, dass die letzte Überprüfung Ihrer Identität bereits vor mehr als einem Jahr stattgefunden hat und deshalb eine Re-Identifikation notwendig ist. Bitte beachten Sie, dass Sie kein neues SwissID Konto anlegen müssen und direkt auf der SwissID App mit der Identifikation starten können. Beginnen Sie direkt in Kapitel 2 der Schritt-für-Schritt Anleitung unter dem folgenden Link:

https://www.swisssign.com/support/dokumentationen/ra-operator-onboarding.html

Die Fristen gelten ab Erhalt der Antragsdokumente und können nur eingehalten werden, wenn alle Dokumente vollständig und korrekt ausgestellt sind und alle Domain-Einträge korrekt validiert wurden.

Ausstellungsgeschwindigkeit für SSL Zertifikate

• DV SSL Silver (Single-Domain und Wildcard): innert Minuten
• OV SSL Gold (Single-Domain, Multi-Domain und Wildcard): bis 2 Arbeitstage
• EV SSL Gold EV (Single-Domain und Multi-Domain): 5 bis 10 Arbeitstage

Ausstellungsgeschwindigkeit für S/MIME E-Mail ID Zertifikate

• Personal S/MIME E-Mail ID Silver : innert Minuten

Möchten Sie in Zukunft Ihre Zertifikate bei Bedarf schneller beziehen, dann empfehlen wir Ihnen unsere MPKI-Services.

Nach dem Kauf Ihrer Zertifikate im Webshop swisssign.com gehen Sie bitte wie folgt vor, um diese zu beziehen:

• Melden Sie sich in Ihrem Benutzerkonto an.

• Wählen Sie den Tab «Zertifikate» und starten Sie die Aktivierung des gewünschten Zertifikates, indem Sie auf «Ausstellen» hinter dem entsprechenden Eintrag klicken.

• Sie gelangen nun zur technischen Antragstellung Ihres Zertifikates. Folgen Sie dazu den Anweisungen im Antragsprozess.

• Sobald Ihr Antrag geprüft und akzeptiert ist, erhalten Sie eine E-Mail mit dem Link, über den Sie Ihr Zertifikat herunterladen können.

1. Loggen Sie sich in Ihr Webshop-Benutzerkonto auf swisssign.com ein.

2. Öffnen Sie im Tab «Zertifikate» den gewünschten Eintrag.

3. Die Codes werden angezeigt. Klicken Sie auf «Share» um den korrekten Link zu kopieren.

4. Teilen Sie den Link mit der anderen Person.

5. Die andere Person kann mit diesem Link nun die technische Antragsstellung des Zertifikates direkt durchführen. Sie benötigt keinen Shop-Account dafür.

Die alten Lizenzcodes können Sie auf der Enrollment-Webseite eingegeben: portal.shop.swisssign.com/enrollment

Die hohen Sicherheitsstandards im Zertifikatsgeschäft verlangen, dass Sie die Unterschriften der bevollmächtigten Personen bei einem weiteren Zertifikatsantrag erneut einholen und uns zusammen mit den entsprechenden Kopien der IDs/Pässe zukommen lassen.

Um den Prozess bei einem mehrfachen Kauf von Zertifikaten zu vereinfachen, können Sie sich von den Verantwortlichen Ihrer Organisation bevollmächtigen lassen: Vollmachtsformular (PDF, 106 KB). Bitte weisen Sie bei jeder Bestellung auf diese Vollmacht hin oder fügen Sie eine Kopie bei.

Benötigen Sie regelmässig Zertifikate? Dann lohnt sich für Sie unser Managed PKI Zertifikat Service bei dem Sie zusätzlich von attraktiven Volumenrabatten profitieren.

Bitte kontaktieren Sie unseren Support.

1. Loggen Sie sich auf swisssign.com ein.

2. Suchen Sie in Ihrem Konto nach dem entsprechenden Antrag.

3. Drucken Sie das Formular erneut aus.

Um Ihr Zertifikat aus unserem Webshop zu revozieren, benötigen Sie den Revokationslink aus dem E-Mail der entsprechenden Ausstellung.

Der Zeitstempel Dienst/Time Stamping Dienst (TSA) ist der Service einer CA, der eine mit dem Datum, der Uhrzeit und einer Signatur der CA versehene Bescheinigung abgibt, wonach bestimmte digitale Daten zu einem bestimmten Zeitpunkt existiert haben. Der SwissSign Zeitstempeldienst entspricht der Schweizer Gesetzgebung (ZertES).

Digitale Zeitstempel dienen vorwiegend zur zeitgenauen Archivierung von Dokumenten oder zum Kennzeichnen von geschäftlichen Dokumenten wie etwa Verträgen. Des Weiteren legt die schweizerische Gesetzgebung fest, dass eine qualifizierte Signatur nur dann einer eigenhändigen Unterschrift gleichgestellt ist, wenn sie mit einem «qualifizierten» Zeitstempel versehen ist. Die SwissSign Zeitstempel können für Workflow- und Archivierungslösungen eingesetzt werden. Obwohl jede elektronische Signatur bereits eine Zeitangabe enthält (lokale Systemzeit), kann es nützlich sein, eine von externer Seite beglaubigte Zeit mit den Daten und Dokumenten zu verbinden. So kann jederzeit einfach und transparent nachgewiesen werden, dass der entsprechende Datensatz zu einem bestimmten Zeitpunkt existiert hat und seit exakt dem Zeitpunkt der Stempelung nicht mehr verändert wurde (Integrität).

Einsatz: Zum Beispiel bei Lösungen zur Umsetzung von gesetzlichen Anforderungen wie GeBüV, Compliance-Regelwerken wie SOX, Basel II oder branchenspezifischen Qualitäts-Frameworks wie GMP.

Der Zeitstempel ist technisch gesehen eine Signatur der Anbieterin, welche eine vertrauenswürdige Zeit beinhaltet. Die Erzeugung dieses Zeitstempels findet durch die Time Stamping Authority (TSA) gemäss RFC 3161 statt. Das Protokoll RFC 3161 definiert, dass die Anfrage den Hashwert enthält und dieser dann durch die TSA signiert wird. Dadurch wird gewährleistet, dass der TSA-Dienst über den Inhalt der zeitgestempelten Dokumente nichts erfährt.

Mehr dazu erfahren Sie hier.

Hintergrund ist die historisch bedingte Anpassung des Zeitstempeldienstes an die neuen Sicherheits-Anforderungen und den damit um einige Bytes vergrösserten Umfang der Rückantwort an das Adobe Programm. In seiner normalen Konfiguration ist Adobe hierauf nicht vorbereitet. Es gibt daher seitens Adobe den Hinweis, in der Registry die iSize zu vergrössern.

Als Beispiel dient der nachfolgende Patch für Adobe Reader DC. Hierfür speichern Sie dafür den passenden Text als Datei «fix_adobe.reg» ab und führen Sie einen Doppelklick aus, um die Änderung an der Registry zu bewirken. Es wird empfohlen, vorab die Registry zu sichern. Bedenken Sie, dass das Registry File immer spezifisch für die Adobe Version ist und daher der Text ggfs. modifiziert werden muss. Z.B. kann der Teil des Pfades, welcher nachfolgend mit «Adobe Reader» bezeichnet wird, auch «Adobe Acrobat» lauten. 

Für Acrobat Reader:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\Security\cASPKI\cAdobe_TSPProvider]

"iSize"=dword:00002800

Für Adobe Acrobat Pro:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\DC\Security\cASPKI\cAdobe_TSPProvider]

"iSize"=dword:00002800