Webserver-Zertifikat auf lokalen Servernamen (nur Zugriff im lokalen Netzwerk)?

[Bib]

Hallo,
ich hab gerade ein kleines Problem und irgendwie weiß niemand so recht was damit anzufangen, daher mal die Frage hier:

Wir haben eine Software auf unserem lokalen Windows-Server installiert, auf die man auch per Android- oder iOS-App zugreifen kann. Das geht über https mit Port 443. Der Zugriff erfolgt ausschließlich über im lokalen Netzwerk eingeloggte Endgeräte, nicht übers Internet.
Laut Software-Anbieter benötige ich jetzt ein von einer Zertifizierungsstelle (z.B. digicert.net) ausgestelltes Webserver-Zertifikat, ausgestellt auf den lokalen Servernamen (z.B. srv-main01).

Mir wurde erklärt, dass die Android-Geräte den Zugriff verweigern, wenn da kein Zertifikat für den Server installiert ist... Man könne sowas auch selbst machen, wenn man ein eigenes root-Zertifikat macht und dann selbst ein webserver-Zertifikat ausstellt, aber er meinte, das wäre ein zu großer Aufwand dafür... Wir sollen ein Zertifikat beschaffen und dann läuft es. Er kann uns kein Zertifikat bestellen, dass müssen wir selber organisieren.

Auch unsere betreuende EDV-Firma ist ein wenig ratlos, wobei der Zertifikatsexperte gerade nicht erreichbar war und die anderen Kollegen dazu nur wenig wussten.

Die Fragen:

Gibts irgendwo eine Schritt-für-Schritt Anleitung für sowas?

Welche Zertifizierungsstelle ist zu empfehlen?

Kann eine öfftl. Zertifizierungsstelle für unseren lokalen Server so ein Zertifikat ausstellen, also auf den lokalen Servernamen?

 

[martingo]

Meiner Meinung nach ist das nicht möglich (bzw. die kommerziellen Zertifizierungsstellen dürfen das nicht).
Die Eigentümerschaft ist bei lokalen Namen/Domänen nicht nachweisbar.
Du lässt Dir bei Stelle A ein Zertifikat für srv-main01 erstellen.
Ich lasse mir bei Stelle B ein Zertifikat für srv-main01 erstellen. Und schon kann ich fröhlich man-in-the-middle spielen und alles bleibt grün.

Entweder das selbstsignierte Zertifikat auf die Geräte als vertrauenswürdig importieren oder eine Root CA betreiben und das Root Zertifikat auf die Geräte verteilen. Möglichkeit 2 ist zu bevorzugen.
Möglichkeit 3 wäre, auch intern die öffentliche Domain zu verwenden (auch wenn der Server nur intern erreichbar ist), also z.B. srv-main01.example.org. das Zertifikat gilt dann aber auch nur für den FQDN. DNS kann ja auf interne IP zeigen.

 

[Seelbreaker]

Wenn der FQDN des Windows Servers = Public FQDN ist, dann könnte auch ein LetsEncrypt Zerti weiterhelfen.

 

[tolga9009]

Je nach Router kann man z.B. intern.example.com als interne FQDN verwenden. Innerhalb des lokalen Netzwerks wird dann über den internen DNS des Routers aufgelöst (und bei korrekter Konfiguration DNS Anfragen *.intern.example.com nicht extern weitergeleitet). Von extern lässt man das ganze einfach ins Leere laufen oder verweist auf example.com. Über z.B. VPN könnte man dann bei Bedarf dennoch von extern auf die internen Services zugreifen. Vorteil von eigenen Domains / Subdomains ist, dass ihr volle Kontrolle habt. Euch fliegt also nicht die komplette Infrastruktur auseinander, wenn der ICANN eines Tages auf die bekloppte Idee kommt, .lan oder .local als Top Level Domains anzubieten (unwahrscheinlich, aber nicht unmöglich, siehe letzte Monate zu .org-Domains). Und ihr seid flexibler, wenn ihr doch mal einzelne Services für das WWW öffnen wollt.

Zum Thema: Root CA selbst signieren, Zertifikat in Clients importieren. Das ist nicht so kompliziert. Wenn es sich nur um eine Hand voll Zertfikate handelt, dann nimmste am besten OpenSSL "Roh" in der Kommandozeile.

Eine gute up-to-date Anleitung, der man einfach so halb-blind folgen kann, habe ich bisher noch nicht gefunden. Wenn du aber folgende Anleitungen "kombinierst", sollte das richtige bei rauskommen:

Eine eigene OpenSSL CA erstellen und Zertifikate ausstellen

Dieser Beitrag erklärt, wie ihr in < 5 Minuten eine eigene Certificate Authority (CA) erstellt und eigene Zertifikate ausstellt.

legacy.thomas-leister.de

Self Signed Certificate with Custom Root CA

Self Signed Certificate with Custom Root CA. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

OpenSSL - ArchWiki

wiki.archlinux.org

Für den CA am besten einen eigenen Container / VM erstellen mit FQDN, z.B. ca.intern.example.com. Der signiert dir dann die CSRs von srv-main01.intern.example.com usw.

Wenn ihr sowas häufiger braucht / machen wollt, lohnt sich ein Blick Richtung openxpki. Alternative ist FreeIPA aka "Identity Management" unter RHEL, welches mit Dogtag daherkommt (und auch LDAP / Kerberos etc.).

 

[aranax]

Zum Thema: Root CA selbst signieren, Zertifikat in Clients importieren. Das ist nicht so kompliziert. Wenn es sich nur um eine Hand voll Zertfikate handelt, dann nimmste am besten OpenSSL "Roh" in der Kommandozeile.

Macht halt 0 Spaß, dass auf X Androids und iPhones zu hinterlegen.

Entweder "richtige" Doman intern auflösen oder einfach auf https verzichten, je nachdem was die Anwendung so tut, ist ja schliesslich das eigene Netz.

 

[flxmmr]

man kann ja auch mal ein self-signed-Zertifikat probieren, dann kann man gleich mal sehen, wie sicher die App wirklich ist

 

[fdsonne]

Auch unsere betreuende EDV-Firma ist ein wenig ratlos, wobei der Zertifikatsexperte gerade nicht erreichbar war und die anderen Kollegen dazu nur wenig wussten.

Ehrliche Antwort? Sucht euch bitte einen anständigen Dienstleister!!
Also wenn da nichtmal Basics vorhanden sind - und nur eine einzige Person im Unternehmen, welche als Dienstleister für euch in so einem Bereich fungieren sollte, in der Lage ist, eine Aussage zur Nutzung von Zertifikaten zu geben, dann würde ich mir persönlich als Nutzer schon Gedanken machen, ob man mir dort helfen kann für mein Geld, wenn mal ein richtiges Problem ist... Vor allem, wenn du dann in einem public Forum, wo mehr oder weniger Hobby-ITler die Regel sind, um Rat fragst.


Btw. zu deinem Anliegen, der Anbieter dort hat natürlich recht. Auch wenn die Wortwahl vielleicht nicht gaaanz passt.
Es geht dabei darum, dass es notwendig ist ein Zertifikat nicht nur auszustellen (grundsätzlich reicht es eigentlich, wenn der Webserver den privaten Schlüssel hat und schon kann er verschlüsselte Verbindungen "anbieten") sondern auch, dass das Endgerät - in eurem Fall wohl Smartphones - diesem Key vertraut.
Dafür gibt es eine Zertifizierungsstelle die dir die Gültigkeit wenn man das so sagen kann, eines Zertifikats sozusagen beglaubigt. Ohne dabei jetzt zuuuu sehr ins Detail zu gehen. Vom Prinzip her ganz vereinfacht gesagt - du füllst einen Antrag aus (ein sogeannnter CSR - certificate signing request), die CA (certificate authority) signiert mit ihrem Schlüssel diesen CSR und gibt dir ein Zertifikat. Den sogenannten public Key. Irgend ein schlauer "Kopf" hat sich damals mal einfallen lassen, dass sogut wie jedes Endgerät einer Reihe von public verfügbaren CAs automatisch und ohne dein Zutun vertraut - und damit allen Zertifikaten, welche durch diese signiert werden.

-> das ist sozusagen der Hintergrund, warum der Anbieter da meint, das ist zu viel Aufwand es selbst zu machen respektive public Cert macht es einfacher. Man muss sich nicht um das "Vertrauen" kümmern.

Es dauert theoretisch nur ne Hand voll Minuten, via OpenSSL oder einer Enterprise PKI von Microsoft über Windows Server eine CA zu erstellen und diese sogenannte Self Signed Zertifikate signieren zu lassen. Das funktioniert so lange 1a, wie du in der Lage ist, diese eigene CA auf die Endgeräte zu bringen. In einem Microsoft Client PC Umfeld geht das über das AD oder über GPOs. Im Linux Umfeld ist es etwas umständlicher, aber lange auch händelbar über bspw. so Sachen wie Ansible. Bei mobilen Endgeräten wie Smartphones oder Android/IOS Tables ist das allerdings ggf. schon ein recht großes Problem - wenn ihr keine MDM Lösung habt! Habt ihr das? -> schmerzfrei, Root CA Zertifikat auf den Clients in den Trust Store hinterlegen, fertig...



GAAAAANZ WICHTIG, wenn ihr eine Self Signed Infrastruktur dafür aufziehen wollt. Sichert den private Key für die CA ab. Kommt der Key weg, wäre Jeder, der diesen hat, in der Lage Zertifikate auszustellen mit jedem beliebigen Namen und all eure Clients, die dieser CA vertrauen, würden das akzeptieren. Da hilft je nach Umsetzung dann auch kein Fancy Security Zeugs irgendwelcher Anbieter - das kann richtig übel schief laufen. Also Obacht, wer da wie Zugriff hat!

Gibts irgendwo eine Schritt-für-Schritt Anleitung für sowas?

Welche Zertifizierungsstelle ist zu empfehlen?

Kann eine öfftl. Zertifizierungsstelle für unseren lokalen Server so ein Zertifikat ausstellen, also auf den lokalen Servernamen?

Zum ersten, ja - Anleitungen zu OpenSSL gibts zu Hauf. Alternativ die MS Lösung, die ist Klicki Bunti - da gibts haufenweise Lesestoff dazu bei Microsoft, wenn du einfach nach Enterprise PKI How To googlest. Bei OpenSSL das gleiche. Im Endeffekt ist die Basis bei OpenSSL mit ein paar ganz wenigen Befehlszeilen erschaffen.

Zum zweiten, komplett Ansichtssache. Ich nutze Globalsign für manche gekaufte Zertifikate. Und habe auch Lets Encrypt im Einsatz - weil kostet nix. Lets Encrypt ist allerdings eher für Automatisierung geeignet anstatt für manuelle Ausstellung. Die Gültigkeit der Zertifikate ist maximal 90 Tage. Renew dann alle ~60 Tage. Das macht man nicht mehr manuell, sondern wenn dann automatisch.

Zum dritten, theoretisch ja, praktisch könnte es aber ein Problem sein. Die Frage ist eher, wie ist der Server konfiguriert, kann er über einen FQDN angesprochen werden und ist die Domain, die verwendet wird, in eurem "Besitz", respektive ist diese public verfügbar?
Bei Lets Encrypt brauchts dann einer Challenge, sprich du brauchst den Namen von dem Lets Encrypt Server aus erreichbar, der Cert-Client fragt den LE Server an, bekommt einen String zurück, dieser wird der LE Server hinter der Domain aufrufbar erwarten - wenn er das kann, dann stellt er dafür ein Zertifikat aus.
Bei anderen CAs, wo man meist auch Geld zahlt für die Zertifikate, geht das auch "Offline" - bspw. wenn die Domain Registriert ist und ein Key im public DNS hinterlegt werden kann - oder über eine Art Mail Challenge -> Bestätigung dass ihr der Owner der Domain seid über die postmaster@domain.tld Mailadresse oder oder oder.

Btw. eine öffentliche CA wird dir ziemlich sicher nur Zertifikate ausstellen, wo FQDNs drin sind. Kurznamen für bspw.: "https://servernamekurz" wird nicht funktionieren. "https://a.b.c.d" in Form einer IP wird auch nichts werden. Vor allem nicht private IPs. IPv6 weiß ich ehrlich gesagt aus dem Hut gar nicht!?? -> du brauchst nen FQDN. -> "https://servernamekurz.domain.tld"
Exakt über diesen müssten die Clients dann den Server ansprechen -> mit dem Kurznamen oder der IP kommt dann ein Zertifikatsfehler.

Entweder "richtige" Doman intern auflösen oder einfach auf https verzichten, je nachdem was die Anwendung so tut, ist ja schliesslich das eigene Netz.

Absolut schlechte Idee!
Man verzichtet nicht auf Verschlüsslung, nur weil es eh das eigene Netz ist... Denke einfach mal einen Schritt weiter - hier wird über Smartphones gesprochen -> was hindert MA 1 mit nem Sniffer deine unverschlüsselte Verbindung im selben WLAN mitzuschneiden und damit irgendwelche Daten von MA 2 zu "erheben"??
Nur weil es geht und einfach ist, macht es das nicht sinnig!

 

[fdsonne]

Offline meint in dem Fall, dass du auch ein Zertifikat für 2 Jahre oder gar noch länger ausstellen kannst - bei LE sind es 90 Tage, das halte ich auf Dauer nur für eine Online Lösung für praktikabel. Oder man muss sich was basteln um irgendwo eine URL Erreichbar zu machen oder via DNS Challange zu arbeiten und das Zertifikat dann automatisiert in ein anderes System zu übertragen oder vom Server selbst aus die DNS Einträge setzen zu können. Kann man machen, aber mal ehrlich, hier fragt wer in nem öffentlichen Forum was ein Software Anbieter meint und sein Dienstleister nicht versteht - meinst du der Jenige baut sich da was? Ich denke mal nicht...