2
Https Zertifikat an eigener CA ausstellen lassen - Common Name obsolet?
Hallo Zusammen,
ich muss für eine Applikation welche über den Webbrowser startet bei uns intern im Intranet ein SSL Zertifikat erstellen, sodass die Applikation über https geöffnet wird und nicht mehr über http.
Nun haben wir seit ein paar Monaten eine eigene CA auf einem Windows Server 2019. Auf dem Server habe ich schon mehrere Zertifikate angefordert und erstellt, z.B. für Office Makro Signierungen.
Jetzt möchte ich noch ein https Zertifikat an der CA anfordern. Das Rollout Template besteht dazu bereits und ich kann nach der Anleitung mit den Steps ein Zertifikat erstellen:
https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-ma ...
Nun stellt sich mir die Frage bei den Certification Properties, ob man noch über den Weg fährt und einen CommonName mit der hintenstehender URL angibt oder dies nun über den DNS Eintrag aka Subject Alternative Name (SAN) macht.
Wenn man hier nachliest, scheint es das manche Browser nicht mehr auf dem CommonName achten sondern auf den Subject Alternative Name.
https://www.heise.de/security/artikel/Chrome-blockt-Zertifikate-mit-Comm ...
Wie ist das richtige vorgehen? Sollte ich einfach beides setzen, den common name und den SAN mit dem gleichen Inhalt?
Was braucht es sonst noch beim Erstellen eines SSL Zertifikates für https Anfragen? Der private key sollte beim erstellen exportiert werden nehme ich an, wo benötige ich später den private key? Nur wenn ich das Zertifikat noch auf einem anderen Webserver installieren möchte oder gibt es noch weitere Kriterien die man beim Erstellen des Zertifikats beachten sollte?
Danke und Gruss
staybb
ich muss für eine Applikation welche über den Webbrowser startet bei uns intern im Intranet ein SSL Zertifikat erstellen, sodass die Applikation über https geöffnet wird und nicht mehr über http.
Nun haben wir seit ein paar Monaten eine eigene CA auf einem Windows Server 2019. Auf dem Server habe ich schon mehrere Zertifikate angefordert und erstellt, z.B. für Office Makro Signierungen.
Jetzt möchte ich noch ein https Zertifikat an der CA anfordern. Das Rollout Template besteht dazu bereits und ich kann nach der Anleitung mit den Steps ein Zertifikat erstellen:
https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-ma ...
Nun stellt sich mir die Frage bei den Certification Properties, ob man noch über den Weg fährt und einen CommonName mit der hintenstehender URL angibt oder dies nun über den DNS Eintrag aka Subject Alternative Name (SAN) macht.
Wenn man hier nachliest, scheint es das manche Browser nicht mehr auf dem CommonName achten sondern auf den Subject Alternative Name.
https://www.heise.de/security/artikel/Chrome-blockt-Zertifikate-mit-Comm ...
Wie ist das richtige vorgehen? Sollte ich einfach beides setzen, den common name und den SAN mit dem gleichen Inhalt?
Was braucht es sonst noch beim Erstellen eines SSL Zertifikates für https Anfragen? Der private key sollte beim erstellen exportiert werden nehme ich an, wo benötige ich später den private key? Nur wenn ich das Zertifikat noch auf einem anderen Webserver installieren möchte oder gibt es noch weitere Kriterien die man beim Erstellen des Zertifikats beachten sollte?
Danke und Gruss
staybb
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 572738
Url: https://administrator.de/contentid/572738
Ausgedruckt am: 15.11.2024 um 14:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo,
Der Heise Artikel zitiert nicht ganz vollständig. https://tools.ietf.org/html/rfc2818#section-2.4 führt aus:
Sicherlich macht es Sinn, zwischen Subject Alternativ Name und Antragsstellernamen zu unterscheiden. So sind ja durchaus mehrere Subject Alternativ Names für einen Antragssteller möglich (und oft auch Realität). Den Common Name braucht das Zertifikat nach X.509 trotzdem/weiterhin.
Na dass die Clients dem Zertifikatherausgeber vertrauen. Das Zertifikat muss sich aus Sicht des Clients auf eine vertrauenswürdige Zertifizierungsstelle zurückführen lassen. Diese muss entweder automatisch verteilt werden (Active Directory?) oder manuell (dem Browser oder dem PC) hinzugefügt werden.
Grüße
lcer
Der Heise Artikel zitiert nicht ganz vollständig. https://tools.ietf.org/html/rfc2818#section-2.4 führt aus:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.Sicherlich macht es Sinn, zwischen Subject Alternativ Name und Antragsstellernamen zu unterscheiden. So sind ja durchaus mehrere Subject Alternativ Names für einen Antragssteller möglich (und oft auch Realität). Den Common Name braucht das Zertifikat nach X.509 trotzdem/weiterhin.
Was braucht es sonst noch beim Erstellen eines SSL Zertifikates für https Anfragen?
Na dass die Clients dem Zertifikatherausgeber vertrauen. Das Zertifikat muss sich aus Sicht des Clients auf eine vertrauenswürdige Zertifizierungsstelle zurückführen lassen. Diese muss entweder automatisch verteilt werden (Active Directory?) oder manuell (dem Browser oder dem PC) hinzugefügt werden.
Grüße
lcer
Moin,
Gruß,
Dani
Den Common Name braucht das Zertifikat nach X.509 trotzdem/weiterhin.
so ist es.Na dass die Clients dem Zertifikatherausgeber vertrauen.
Und das der Typ, in diesem Serverauthentifizierung, ausgewählt wurde.Gruß,
Dani
