Laden...

ASP.NET MVC Interner Webserver HTTPS

Erstellt von TirolerToni vor 2 Jahren Letzter Beitrag vor 2 Jahren 322 Views
T
TirolerToni Themenstarter:in
12 Beiträge seit 2011
vor 2 Jahren
ASP.NET MVC Interner Webserver HTTPS

Hallo!

Ich habe eine ASP.NET MVC Webanwendung auf einen internen Webserver mit Windows Authentifizerung im Einsatz.
Soweit läuft alles einwandfrei.

Jetzt möchte ich, dass diese Webanwendung mit HTTPS funktioniert.
Im Browser (zb Chrom) soll keine HTTPS Warnmeldung erscheinen.

Welches Serverzertifikat benötige ich hierfür?
* Selbstsigniertes Zertifikat
* Domänenzertifikat
* Zertfikat kaufen

Vielen Dank für eure Hilfe im Voraus.
Lg Toni

T
2.224 Beiträge seit 2008
vor 2 Jahren

Eigentlich sollte das auch mit Lets Encrypt ohne extra kosten laufen.
Zertifikate für https muss man sich heute wirklich nicht mehr kaufen.

Google sollte aber passende Treffer haben:
Google Suche nach "asp.net mvc ssl certificate"

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.835 Beiträge seit 2008
vor 2 Jahren

Einfach nach HTTPS Zertifikat googlen, dann wird überall erklärt, was das ist, was Du brauchst und wo Du das her bekommst: Du brauchst ein SSL Zertifikat.
Unter Windows wird das als als PFX-Zertifikat im System importiert (OpenSSL Zertifikate von vielen Anbietern muss man umwandeln) und kann das dann über die System Management Console den IIS Instanzen zuweisen.

Mit ASP.NET hat das an dieser Stelle wenig zutun; ist aber wie gesagt sehr gut bei allen Anbietern dokumentiert.
Für Windows Server gibt es mittlerweile auch genannte Lets Encrypt Dienste, die die Zertifikatsbeschaffung über MMC automatisieren.

Eigenes Zertifikat geht nur, wenn auf allen Maschinen das Root Certificate importiert ist (was auch im Enterprise Bereich nicht überall der Fall ist).
Ist dies gegeben, könnt ihr euch das PFX einfach selbst erzeugen. Lets Encrypt geht nur mit echten Domains, nicht mit internen Adressen.

T
TirolerToni Themenstarter:in
12 Beiträge seit 2011
vor 2 Jahren

Hallo!

Ich habe leider schon unzählig viele Google Tutorial und Dokumentationen durchgewühlt aber leider bisher ohne Erfolg.
Ich kann es leider nur (wie folgt chaotisch) schildern. Vielleicht ist irgendwo ein Punkt dabei der meine Situation (oder meinen Denkfehler) beschreibt.

Vorab:
* Ich habe einge externe Webserver mit funktionierenden (altmodisch gekauften) HTTPS Zertifikate im Einsatz.
Alle Problemlos aber natürlich extern und anstelle von WinAuth natürlich Benutzerkonten.

Mein Problem hier jetzt betrifft internen Webserver mit aktivieren WinAuth.

Paar meiner Tests:
* In VS eine neue ASP.NET MVC Webanwendung mit WinAuth und aktivierten SSL erstellt & F5: Klappt sofort.
* Die Webanwendung auf internen IIS Webserver publiziert:
--> HTTP klappt sofort
--> HTTPS Warnmeldung vom Chrom Browser.
* Unzählige Versuche mit "Domänen Zertifikat" & "Selbstsigniertes Zertifikat" am IIS Webserver erstellt und am Rechner wiederum mittels mms/Zertifikate/Lokaler Computer/Vertrauenswürdige Stammzertifizierungsstelle importiert. Alle Schreibweise (mit DNS Suffix ohne DNS Suffix usw. probiert.
* (Ich hab es auch mit unseren externen WildCard-Zertifikat auf dem internen Webserver probiert. Das klappt sogar bis zu dem Zeitpunkt wo ich WinAuth aktiviere. Dann verlangt er nämlich ein Benutzername und Kennwort? Daher glaub ich mal, dass das nicht der richtige Weg ist...)
* Verrücktester Punkt: Wenn ich FIDDLER (Webdebugging Tool) gestartet habe, dann funktioniert es.
* Getestet hab ich alle Schritt auf und ab auf 4 verschiedenen internen Webserver. (Beim ersten lag es am veralteten TLS 1.0 / TLS 1.1...)
* Wenn ich die Fehlermeldung ignoriere, dann klappt es sofort und es kommt auch keine Benutzer/Kennwort Aufforderung.
Aber egal was ich bisher probierte ich bekomme die Meldung nicht weg.

Im Augenblick stehe ich hier (nach 2 Tagen NonStop Lösungssuche) komplett an.
Lg

16.835 Beiträge seit 2008
vor 2 Jahren

Wenn ich FIDDLER (Webdebugging Tool) gestartet habe, dann funktioniert es.

Weil Fiddler ein Root Certificate Zertifikat erstellt und auf Deiner Maschine installiert.
Fiddler nimmt jedes Zetifikat an; liefert aber ein eigenes aus - ansonsten könnte Fiddler nicht den Traffic darstellen; nennt sich SSL Interception.
Dadurch funktioniert das natürlich in Chrome.
Das gleiche Verfahren verwendet jeder Firmenproxy.

Wenn Du ein selbst signiertes Zertifikat nimmst, dann geht das nur auf der Maschine, auf der Du das erstellst bzw. importierst - ausser Du erstellst es über das interne Root Certificate, das auf jeder Maschine installiert ist.

Mit WinAuth (den Namen gibt es nicht), wirst Du vermutlich Kerberbos meinen.
Kerberbos is aber ein Authentifizierungsprotokoll und HTTPS ein Verschlüsselungsprotokoll - also zwei paar Stiefel.
Kann sein, dass je nach Browser das Kerberbos Ticket im Header nich mitgegeben wird, wenns nich über HTTPS läuft (was gut so wäre) - hat aber mit HTTPS nichts zutun, sondern dann mit Sicherheitsfeatures des Browsers.

T
TirolerToni Themenstarter:in
12 Beiträge seit 2011
vor 2 Jahren

Hallo Abt!

Weil Fiddler ein Root Certificate Zertifikat erstellt und auf Deiner Maschine installiert.
Fiddler nimmt jedes Zetifikat an; liefert aber ein eigenes aus - ansonsten könnte Fiddler nicht den Traffic darstellen; nennt sich SSL Interception.
Dadurch funktioniert das natürlich in Chrome.
Das gleiche Verfahren verwendet jeder Firmenproxy.

Stimmt: Ich habe von Fiddler folgende Meldung erhalten: "Certficate Error" und [Ignore errors (unsafe) and proceed? YES]. Durch das bestätigen habe ich sozusagen einen Workaround geschaffen. Danke für den Tipp.

Mit WinAuth (den Namen gibt es nicht), wirst Du vermutlich Kerberbos meinen.

Wenn ich ein neues Visual Studio Projekt (MVC) erstelle, dann habe ich die Wahl zwischen "Einzelne Benutzerkonten" und "Windows-Authentifizierung".
Am IIS Webserver muss ich dafür wiederum unter im Menu Punkt: "Authentifizierung" die "Anonyme Authentifizierung" deaktivieren und die "Windows-Authentifizierung" aktivieren.
Das meint ich mit WinAuth.
(Wenn ich rechtsklicks auf IIS/Webprojekt/Authentifizierung/Anbieter... mache, dann steht hier auch noch: Negotiate + NTLM. Falls irgendwie interessant/relevant.)

Wenn Du ein selbst signiertes Zertifikat nimmst, dann geht das nur auf der Maschine, auf der Du das erstellst bzw. importierst

Dh damit kann ich kein Zertifikat selbst signieren und dann über Group-Policy von unserer IT verteilen lassen oder?

ausser Du erstellst es über das interne Root Certificate, das auf jeder Maschine installiert ist.

Das sagt mir jetzt im Augenblick noch nichts. Soll ich hier nach suchen?
Ist das die empfohlene Vorgehensweise wenn man für eine ASP.NET MVC Webanwendung mit Windows-Authentifizierung HTTPS ermöglichen möchte?

Lg

16.835 Beiträge seit 2008
vor 2 Jahren

Hallo Abt! Durch das bestätigen habe ich sozusagen einen Workaround geschaffen. Danke für den Tipp.

Das ist kein Workaround, SSL Interception ist ein Mechanismus "by design".
Im Endeffekt ein Man in the Middle. Les es Dir durch.

Das meint ich mit WinAuth.

Das nennt sich Kerberos.

Wenn Du ein selbst signiertes Zertifikat nimmst, dann geht das nur auf der Maschine, auf der Du das erstellst bzw. importierst
Dh damit kann ich kein Zertifikat selbst signieren und dann über Group-Policy von unserer IT verteilen lassen oder?

Ich kenne eure IT nicht. Normalerweise hat eine interne IT in größeren Unternehmen immer ein selbst erstelltes Root Certificate, das für viele technische Dinge notwendig ist (Signierungen, Authentifizierungen...). Völliger Standard.
Dieses Zertifikat (bzw. den public Teil) wird auf den Firmen-Rechnern verteilt, sodass diese entsprechende Signaturen validieren können.

Die IT erstellt damit aber auch entsprechende TLS Zertifikate für internes HTTPS.
Also melde Dich dort und frag nach, wie das dort geregelt ist. Wir wissen das hier nicht.

T
TirolerToni Themenstarter:in
12 Beiträge seit 2011
vor 2 Jahren

Ich kenne eure IT nicht. Normalerweise hat eine interne IT in größeren Unternehmen immer ein selbst erstelltes Root Certificate, das für viele technische Dinge notwendig ist (Signierungen, Authentifizierungen...). Völliger Standard.
Dieses Zertifikat (bzw. den public Teil) wird auf den Firmen-Rechnern verteilt, sodass diese entsprechende Signaturen validieren können.
Die IT erstellt damit aber auch entsprechende TLS Zertifikate für internes HTTPS.

Danke für den Tipp!!