heise online Logo
Anmelden
Menü
  • c't – Magazin für Computertechnik
  • iX – Magazin für professionelle Informationstechnik
  • MIT Technology Review – Das Magazin für Innovation von Heise
  • c't Fotografie - Das Magazin rund ums digitale Bild
  • Mac & i – Nachrichten, Tests, Tipps und Meinungen rund um Apple
  • Make – Kreativ mit Technik
  • Alle Magazine im Browser lesen
IT News
  • Newsticker
  • heise Developer
  • heise Netze
  • heise Open Source
  • heise Security
Online-Magazine
  • heise+
  • Telepolis
  • heise Autos
  • TechStage
  • tipps+tricks
Services
  • Stellenmarkt heise Jobs
  • Weiterbildung
  • heise Download
  • Preisvergleich
  • Whitepaper/Webcasts
  • DSL-Vergleich
  • Netzwerk-Tools
  • Spielen bei Heise
  • Loseblattwerke
  • iMonitor
  • IT-Markt
Heise Medien
  • heise Shop
  • Abo
  • Veranstaltungen
  • Arbeiten bei Heise
  • Mediadaten
  • Presse
Anzeige Go! Schule morgen
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten
heise Security Logo
  • News
    • Archiv
    • 7-Tage-News
  • Hintergrund
  • heise Security Pro
    • FAQs zu heise Security Pro
  • Events
  • Kontakt
  1. Security
  2. Hintergrund
  3. Chrome blockt Zertifikate mit Common Name

Chrome blockt Zertifikate mit Common Name

Hintergrund 19.05.2017 12:58 Uhr Jürgen Schmidt
Chrome blockt Zertifikate mit Common Name

Wenn der seit Jahren etablierte, hauseigene Dienst plötzlich den HTTPS-Zugang verwehrt, liegt das vermutlich an einer Neuerung der aktuellen Chrome-Version: Google erzwingt den Einsatz der RFC-konformen "Subject Alt Names" und viele Admins müssen deshalb jetzt Hand anlegen.

Chrome verweigert den Zugang zum HTTPS-Dienst, wenn das Zertifikat keinen Subject Alternative Name enthält.
Chrome verweigert den Zugang zum HTTPS-Dienst, wenn das Zertifikat keinen Subject Alternative Name enthält.

Um zu testen, ob ein Zertifikat zum Server-Namen passt, den der Anwender aufruft, vergleicht der Browser die Namen. Es war lange Zeit Usus, dazu den Namen des Servers – etwa www.heise.de – im sogenannten Common Name (CN) des Subject-Felds anzugeben. Allerdings hat der im Jahr 2000 veröffentlichte RFC 2818 davon bereits abgeraten:

"Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."

Mit Chrome Version 58 hat Google da jetzt Ernst gemacht und die Unterstützung für den Abgleich des Server-Namens mit dem CN abgeschafft. Statt dessen müssen alle Namen der Server, die sich mit diesem Zertifikat ausweisen dürfen, über die Erweiterung subjectAltName spezifiziert werden. Gibt es diese nicht, meldet Chrome lapidar: "Subject Alternative Name Missing". Und das betrifft zumindest in Chrome alle Zertifikate ohne Subject Alternative Name (SAN).

Mozilla: Gnade vor Recht

Da geht Google einen Schritt weiter als Mozilla. Die hatten in Firefox die Unterstützung für CNs bereits vor über einem Jahr bei Firefox 48 abgestellt. Allerdings haben sie diese strikte RFC-Auslegung auf neue Zertifikate beschränkt. Außerdem kommt sie nur zur Anwendung, wenn das Zertifikat von einer öffentlichen CA unterzeichnet ist, die im Firefox-Zertifikatsspeicher enthalten ist. Die CAs achten somit notgedrungen bereits seit einiger Zeit darauf, dass Zertifikate einen SAN aufweisen.

Auch Zertifikate, die entweder selbst-signiert oder von einer internen Firmen-CA ausgestellt wurden, nimmt Mozilla von der SAN-Pflicht aus. Google sieht jedoch keine solchen Ausnahmen vor. Diese Vorgehensweise ist heftig umstritten, weil die Formulierungen in den relevanten RFCs durchaus auch andere Interpretationen zulassen. So hat sich etwa im zugehörigen Chrome-Bug-Report eine rege Diskussion ergeben, ob Googles Vorgehensweise tatsächlich RFC-konform ist.

Praxis-Tipps für Admins

Die SANs des Zertifikats finden sich nur in den Angaben zu "Details".
Die SANs des Zertifikats finden sich nur in den Angaben zu "Details".

Doch unabhängig davon, ob Googles Interpretation richtig ist oder nicht, hat der Konzern jetzt Fakten geschaffen und Admins müssen reagieren. Denn viele interne Dienste mit selbst erstellten Zertifikaten funktionieren nicht mehr, wenn die Anwender mit Chrome darauf zugreifen. Die Administratoren müssen also jetzt möglichst schnell neue Zertifikate ausstellen und gegebenenfalls die dazu verwendete Konfiguration beziehungsweise Skripte anpassen.

Das ist leider nicht immer ganz einfach. So kann man bei OpenSSL keine SANs über die Kommandozeile oder mit den vom Benutzer abgefragten Basis-Angaben hinzufügen. Statt dessen muss man in der Konfigurationsdatei eine neue Sektion einrichten. Die hat dann beispielsweise folgenden Inhalt:

subjectAltName = @alt_names
[alt_names]
DNS.1 = www.heise.de
DNS.2 = heise.de
...

Sie muss alle validen Server-Namen enthalten. Auch ein eventuell bereits als CN angegebener Server-Name muss hier erneut auftauchen. OpenSSL zeigt die dann bei den X509-Erweiterungen an:

X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:www.heise.de, DNS:heise.de, ...

Das kann man in einem Skript etwa so abfragen

openssl x509 -noout -text -in $f |\
grep -A 1 "X509v3 Subject Alternative Name" |\
grep DNS | sed -e "s/\s*//"

Microsoft beschreibt die notwendigen Schritte in einem TechNet-Artike How to Request a Certificate With a Custom Subject Alternative Name. Für eine Übergangszeit bis Version 65 kann man Chrome das strikte Verhalten auch mit Hilfe dokumentierter Registry-Keys (Windows) beziehungsweise mit Preferences (Linux/Mac) des Namens EnableCommonNameFallbackForLocalAnchors abgewöhnen.

Wer Tipps zu guten Howtos hat, wie man sich diese Arbeit mit anderen Werkzeugen erleichtert, kann die gerne an mich schicken; ich trage sie dann hier nach.

1. Nachtrag:

  • X.509-Erweiterungen inkl. SAN mit Keystore explorer
  • Zertifikat mit SAN mit Keytool erstellen (Kommandozeilen-Tool in Java)
  • Zertifikat mit SAN via Microsoft Management Console (MMC)

(ju)

Kommentare lesen (9 Beiträge)
Mehr zum Thema
  • Chrome
  • Google
Teile diesen Beitrag
https://heise.de/-3717594 Drucken
Dienste
  • Security Consulter
  • Netzwerkcheck
  • Anti-Virus
  • Emailcheck
  • Krypto-Kampagne
Alerts! alle Alert-Meldungen

Fortinet

IBM-Software

OpenSSL

Django Web-Framework

Anzeige
  • File Sharing im Job ohne Sicherheitsrisiko
  • Wie IT zu nachhaltigem Wirtschaften beitragen kann
  • Kundenservice mit künstlicher Intelligenz
Artikel

Utimaco, der Krypto-Miner und ein Disclosure-Desaster​

Auch Anbieter von Hochsicherheitslösungen sind vor Securityproblemen nicht gefeit. Man sollte sich vorbereiten, bevor man davon erfährt, sagt Jürgen Schmidt.

12 Kommentare
Aufmacher: Kommentar Welt-Passwort-Gedenktag

Kommentar: "Willkommen zum Welt-Passwort-Gedenktag"

Welt-Passwort-Tag: Jürgen Schmidt, Senior Fellow Security bei Heise, hat einen Kommentar aus einer Zukunft ohne Passwörter geschickt.

230 Kommentare
  • Passwortsicherheit – Alles, was Sie wissen müssen
  • Welt-Passwort-Tag: Zugangssicherheit im Fokus

Der Patch-Alptraum: Wenn schnell nicht schnell genug ist

Neben den überbewerteten Zero-Day-Lücken gibt es eine weniger bekannte Bedrohung durch "Beinahe-Zero-Days". Die sind weitverbreitet und brandgefährlich.

95 Kommentare

Neueste Forenbeiträge

  1. Re: WithSecure hängt beim Scannen
    Hallo, ja, Desinfec't ist auf Stand "p3". Ich hab im PC noch zwei 2 TB-Platten die ich aber abgewählt habe. Auf der 240 GB-SSD sind die UEFI-…

    Forum:  Desinfect

    Pit (1) hat keinen Avatar
    von Pit (1); vor 15 Stunden
  2. Re: RAM Belegung nimmt auch waehrend dem Scannen zu
    Hi, weil Desinfec't ein Live-System ist und während des Scannens viel unter der Haube passiert und die Scanner sind ziemlich speicherhungrig.

    Forum:  Desinfect

    Avatar von Dennis Schirrmacher
    von Dennis Schirrmacher; vor 16 Stunden
  3. Re: Desinfec‘t 2022 in Firma einsetzen?
    Jap, das gilt immer noch so wie früher. Viele Grüße des

    Forum:  Desinfect

    Avatar von Dennis Schirrmacher
    von Dennis Schirrmacher; vor 16 Stunden
News und Artikel
  • News
  • 7-Tage-News
  • News-Archiv
  • Hintergrund-Artikel
  • Alert-Meldungen
Service
  • Newsletter
  • Tools
  • Foren
  • RSS
  • mobil
Dienste
  • Security Consulter
  • Netzwerkcheck
  • Anti-Virus
  • Emailcheck
  • Krypto-Kampagne
  • Datenschutz
  • Cookies & Tracking
  • Impressum
  • Kontakt
  • Barriere melden
  • Mediadaten
  • Verträge kündigen
  • 2204297
  • Content Management by InterRed
  • Hosted by Plus.line
  • Copyright © 2022 Heise Medien