Anmerkung der Redaktion: Dieser Blog wurde ursprünglich im März 2017 veröffentlicht. Er wurde von GlobalSign Produktmanager Sebastian Schulz auf Klarheit und Genauigkeit überprüft und entsprechend aktualisiert.

Manchmal haben selbst die effektivsten Website-Verantwortlichen Probleme mit den SSL/TLS-Zertifikaten. In vielen Bereichen können Probleme und Fallen auftreten: bei der Bestellung des richtigen Zertifikats, bei der Erstellung eines CSR, beim Download, bei der Installation und beim Testen.

Wir möchten Ihnen helfen den Vorgang von Anfang bis Ende so einfach wie möglich zu gestalten. Deswegen haben wir die 10 Hauptfragen und Probleme, die unsere Kunden während des Installationsvorgangs beschreiben zusammengefasst. Wir hoffen, dass Sie so diese Fallen vermeiden können und die Installation schneller abschließen. Falls Sie aber ein Problem haben, das nicht in diesem Blog beschrieben wird, können Sie natürlich nach wie vor unser Support-Team kontaktieren oder ein Support Ticket über unsere Website aufgeben. 

Die richtige Genehmigungsmethode auswählen

Es gibt drei Wege auf die Sie Ihre Domain von uns verifizieren lassen können: über eine Genehmigungs-E-Mail, eine Genehmigungs-URL oder über DNS TXT Dateien.  Und wenn Sie es irgendwann leid sind, bei jeder Zertifikatsbestellung die Domains zu verifizieren, warum probieren Sie dann nicht Managed SSL aus?

Bitte beachten Sie: wenn Sie ein SSL-Zertifikat über unser System bestellen, können die Genehmigungsmethoden nach Auswahl nicht mehr geändert werden.

Genehmigungs-E-Mail

Bei der Bestellung können Sie aus den folgenden E-Mail-Adressen zur Verifizierung Ihrer Domain wählen:

• admin@domain.com
• administrator@domain.com
• hostmaster@domain.com
• postmaster@domain.com
• webmaster@domain.com

Es wird eine E-Mail an diese Adresse geschickt und bei Erhalt der E-Mail müssen Sie einen Link klicken, um zu zeigen, dass die Domain Ihre ist.

Bitte beachten Sie: Stellen Sie sicher, dass es die richtige ist. Ansonsten müssen Sie die Bestellung stornieren und eine neue Bestellung aufgeben.

Falls Sie keine der obigen E-Mail-Adressen erstellen können, sprechen Sie bitte mit unserem Support, der Ihnen weitere Optionen erklären kann. Diese sind:

• Ein Update der WHOIS-E-Mail-Adresse (Beispiel einer Website, die GlobalSign nutzt, um Who-Is-Einträge zu prüfen ist networksolutions.com).
• Anhand von Anweisungen unseres Support-Teams eine Seite auf der Website der Domain erstellen. Dies beweist, dass Sie die Domain besitzen und so kann das Vetting-Team eine Genehmigungs-E-Mail an eine beliebige alternative E-Mail-Adresse schicken.

HINWEIS: Ein spezieller Support-Artikel, der Sie durch die Domain-Verifizierung per Genehmigungs-E-Mail führt, ist hier zu finden.

HTTP-Überprüfung

Mit der HTTP-Verifizierungsmethode (auch Approver URL- oder Meta-Tag-Methode genannt) können Sie eine zufällige Zeichenkette, die von GlobalSign bereitgestellt wird, in die Root-Seite Ihrer Domain (zum Beispiel domain.com) einfügen. Das dafür gewählte Verzeichnis muss domain.com/well-known/pki-validation/gsdv.txt sein. 

Unser Verifizierungssystem ist in der Lage, den Meta-Tag auf der Seite zu erkennen und den Besitz der Domain zu überprüfen. Unser System kann die Domain jedoch nicht verifizieren, wenn sie auf eine andere Seite weiterleitet. Stellen Sie daher sicher, dass Sie alle Weiterleitungen deaktivieren.

Hinweis: Einen speziellen Support-Artikel, der Sie durch die Domänenverifizierung per HTTP-Verifizierung führt, finden Sie hier.

DNS TXT-Eintrag

Bei DNS-TXT-Einträgen wird ein Code in die DNS-TXT der registrierten Domäne eingefügt. Sie müssen sicherstellen, dass die Zeichenfolge genau mit den Angaben übereinstimmt, die Sie bei der Bestellung Ihres Zertifikats oder von unserem Prüfteam erhalten haben. Außerdem müssen Sie dafür sorgen, dass der Eintrag öffentlich zugänglich ist. Sie können einige kostenlose Online-Tools verwenden, um Ihre DNS-TXT-Einträge zu überprüfen. Alternativ können Sie auch einen Befehl in der Eingabeaufforderung ausführen, um zu sehen, ob es einen txt-Eintrag gibt, z. B.: nslookup -type=txt domain.com

Hinweis: Einen speziellen Support-Artikel, der Sie durch die Überprüfung der Domäne anhand des DNS-TXT-Eintrags führt, finden Sie hier.

Der private Schlüssel fehlt

Der private Schlüssel und CSR muss immer über den gleichen Server erstellt werden, auf dem auch das Zertifikat installiert wird. Nur so kann das Zertifikat ordnungsgemäß installiert werden. Falls der private Schlüssel nicht mehr auf dem Server gespeichert ist (also verloren gegangen ist), muss das Zertifikat mit einem neuen CSR wiederausgestellt werden.

Folgende Beispiele von Fehlermeldungen lassen vermuten, dass es keinen privaten Schlüssel mehr gibt:

• ‘Private key missing’ erscheint während der Installation.
• Fehlermeldung ‘Bad tag value’ erscheint während der Installation.
• Nachdem das Zertifikat in IIS importiert wurde, verschwindet es wieder aus der Liste, wenn diese aktualisiert wird.
• Wenn Sie auf Ihre Website gehen, wird https:// nicht geladen

Auch wenn es noch so bequem erscheint, möchten wir von der Verwendung von Online-Tools zur Erstellung von CSRs abraten. Diese haben auch Ihren privaten Schlüssel, was bedeutet, dass die Sicherheit Ihres Servers in Zukunft gefährdet sein könnte. 

Hinweis: Wir bieten viele Anleitungen, die Ihnen bei der Erstellung von privaten Schlüsseln und CSRs helfen.

SAN-Kompatibilität

Mit einem SAN (Subject Alternative Name) Zertifikat müssen ein paar Dinge vor der Bestellung beachtet werden.

• UCC (Unified Communication) SANs können kostenlos ausgewählt werden. Diese decken einige direkte Subdomains des Common Name ab (z. B. domain.com):
  1. mail.domain.com
  2. owa.domain.com
  3. autodiscover.domain.com
  4. www.domain.com
• Subdomain-SANs sind auf alle Hostnamen anwendbar, die den Common Name um eine Ebene erweitern. Zum Beispiel:
  • support.domain.com könnte ein Subdomain-SAN für ein Zertifikat mit dem Common Name domain.com sein
  • advanced.support.domain.com kann NICHT durch ein Subdomain-SAN in einem auf domain.com ausgestellten Zertifikat abgedeckt werden, da es sich nicht um eine direkte Subdomain von domain.com handelt.
• FQDN (Fully Qualified Domain Name) SANs gelten für alle voll qualifizierten Hostnamen, die nicht mit dem Common Name verbunden sind
  • support-domain.net könnte ein FQDN SAN in einem Zertifikat mit dem Common Name domain.com sein
  • support.domain.com wäre auch ein gültiger FQDN für ein Zertifikat mit Common Name domain.com, aber die Abdeckung dieser Option mit einem Subdomain-SAN ist die klügere Wahl
  • IP-Adressen können nicht durch FQDN-SANs abgedeckt werden
• SANs für öffentliche IP-Adressen funktionieren nur für registrierte und öffentliche globale IP-Adressen, andernfalls kann der Besitz nicht überprüft werden.
  • Wildcard-SANs funktionieren genauso wie FQDN-SANs, decken aber eine ganze Subdomänenebene ab, unabhängig davon, was für das Sternchen steht
  • Die Wildcard SAN *.domain.com deckt zum Beispiel support.domain.com, gcc.domain.com, mail.domain.com - und so weiter!

Weitere Informationen zur SAN-Kompatibilität zeigt die folgende Grafik.

Falls Sie eine SAN aus Ihrem Zertifikat löschen wollen, nachdem es ausgestellt wurde, folgen Sie den Schritten im Link.

Ungültiger CSR

Falls Sie einen CSR zur Erneuerung des Zertifikats erstellen, müssen Sie sicherstellen, dass die Informationen immer noch gleich wie im ursprünglichen CSR sind. Der neue CSR gleicht nicht dem alten, weil der private Schlüssel anders ist.

Ein weiterer Grund für einen ungültigen CSR ist, wenn ein CSR-Ablauf im IIS7 Server erstellt wurde. Es ist bekannt, dass dabei ein Programmierungsfehler den CSR zu lang macht. Am besten erstellen Sie eine komplett neue Zertifikatsanfrage, anstatt diese nur zu erneuern.

Sie können einen CSR testen, indem Sie einen Decoder der unten genannten Websites nutzen. Auch falls extra Leerzeichen oder zu viele oder zu wenige Bindestriche am Anfang/Ende des Zertifikatsantrags eingefügt wurden, ist der CSR ungültig.

-----BEGIN CERTIFICATE REQUEST-----

-----END CERTIFICATE REQUEST-----

Der eingegebene Common Name stimmt nicht mit der Base Option überein

Dieser Fehler wird angezeigt, wenn Sie ein Wildcard SSL Zertifikat bestellt haben, aber das Sternchen im Common Name (z.B. *.domain.com) nicht hinzugefügt wurde. Oder falls Sie umgekehrt *.domain.com angegeben haben, aber kein Wildcard Zertifikat ausgewählt haben.

Das [*] repräsentiert alle Sub-Domains, die mit dieser Art von Zertifikat gesichert werden können. Falls Sie zum Beispiel www.domain.com, mail.domain.com und secure.domain.com sichern wollen, müssen Sie als Common Name im CSR *.domain.com angeben.

Bitte beachten Sie: Sie können keine Wildcard für eine Sub-Domain vor dem Sternchen erstellen, also z.B. mail.*.domain.com oder doppelte Wildcards, wie *.*.domain.com.

Fehlermeldung: doppelter Schlüssel

Diese Fehlermeldung erscheint, wenn Sie einen schon genutzten privaten Schlüssel nochmal nutzen. Ein privater Schlüssel und CSR können jeweils nur EINMAL genutzt werden.

Sie müssen einen neuen privaten Schlüssel und CSR auf dem Server erstellen und den neuen CSR wieder einreichen.

Bestellstatus wurde bereits geändert

Diese Fehlermeldung erscheint wenn Ihre Bestellung nicht innerhalb eines Zeitlimits fertiggestellt wurde. Sie müssen den Bestellvorgang erneut beginnen und uns mitteilen, falls diese Fehlermeldung weiterhin auftritt. Falls dies der Fall ist, müssen wir weitere Checks in Ihrem Account durchführen.​

Bitte beachten Sie: die Fehlermeldung kann auch bei falsch eingegebenen SANs auftreten. Falls zum Beispiel der Common Name „www.domain.com” ist und Sie als Sub-Domain „domain.domain2.com“ angeben, obwohl dies FQDN anzeigt. 

Die angegebenen SAN Optionen stimmen nicht mit den SAN Optionen des ursprünglichen Zertifikats überein

Dieses Problem kann aus mehreren Gründen auftreten:

• Sie haben ein Leerzeichen nach dem SAN eingegeben, was von unserem System als Fehler angezeigt wird.
• Es befindet sich ein Tippfehler in den eingegebenen Informationen.
• Sie geben den Common Name (CN) des Zertifikats als SAN ein. Das System kann so nicht erkennen, ob es bereits vom Zertifikat gesichert ist.
• Sie haben die SAN fälschlicherweise als Sub-Domain, Multi-Domain Name, interne SAN oder IP eingegeben. Sie müssen die richtige Art von SAN auswählen, die zu der SAN gehört. 

Zertifikat wird vom Browser nicht als vertrauenswürdig anerkannt

Nach der Installation des Zertifikats zeigen manche Browser immer noch Fehler bei der Vertrauenswürdigkeit an. Dies kommt vor, wenn das Intermediate Zertifikat nicht installiert wurde oder das GlobalSign Root-Zertifikat von dem Kunden fehlt, der sich mit Ihrem Server verbindet. Sofern der Kunde nicht stark manipuliert wurde, sollte dies nicht vorkommen - unsere Root-Zertifikate sind in praktisch alle modernen Betriebssysteme und Anwendungen integriert.

Sie können einen SSL-Check für die Domain durchführen, um diesen Fehler aufgezeigt zu bekommen.

Mehr Informationen zu Intermediate Zertifikaten und warum Sie diese nutzen sollten, erfahren Sie in diesem Artikel

Fehlermeldung ‘Wechsel von anderem Anbieter’

Wenn Sie die Option ‚Wechsel von anderem Anbieter‘ in unserem Bestellsystem wählen, kann es sein, dass die folgende Fehlermeldung angezeigt wird:

Der Server, der Ihr derzeitiges Zertifikat anzeigt, kann nicht kontaktiert werden, um die Gültigkeit zu bestätigen. Bitte besorgen Sie sich eine Kopie Ihres Zertifikats und kopieren Sie es in den Kasten unterhalb. Alle Wechsel von Mitbewerbern werden vom GlobalSign Vetting Team auf vertrauenswürdige Anbieter geprüft. Falls Ihr Zertifikat ohne gültiges Root CA Zertifikat ausgestellt wurde, wird es storniert oder zurückgezogen.

Diese Fehlermeldung tritt auf, wenn Ihr derzeitiges Zertifikat nicht länger gültig ist. Wählen Sie diese Option nur, falls Sie vor dem Ablauf Ihres Zertifikats von einem anderen Anbieter wechseln.

Diese Fehlermeldung kann auch auftreten, falls Ihr derzeitiges Zertifikat nicht auf der Domain installiert ist. Unser System kann so die Gültigkeit nicht erkennen. In diesem Fall sollten Sie diese Option nicht wählen und den Bestellvorgang ganz normal durchführen.

Falls Sie ein gültiges Zertifikat von einem anderen Anbieter haben, das nicht auf dem Server installiert ist, kopieren Sie bitte den CSR in das Textfeld der Option ‘Wechsel von einem anderen Anbieter’. Die folgende Abbildung zeigt diese Option.

Diese Fehlermeldung kann zu guter Letzt auch auftreten, wenn Sie ein Zertifikat auf Ihrem Server installiert haben, aber der CN nicht der gleiche wie der Domainname ist. Dies kann zum Beispiel bei einem SAN Zertifikat der Fall sein. In diesem Fall sollten Sie diese Option nicht auswählen und den Bestellvorgang ganz normal durchführen.

Mehr Informationen zu allgemeinen SSL Zertifikatsproblemen finden Sie im SSL-Bereich unserer Supportseite.