Create valid self-signed cert failed

Hallo Community,

ich kämpfe mal wieder mit der Erstellung valider self.signed certificates für mein homelab.

Ich möchte gerne für einige Services wie z.B: Nextcloud, Bitwarden, Portainer usw... https / ssl auch in meinem home network nutzen. Setup ist meist Service läuft auf VM oder LXC in Proxmox unter http. Nginx als reverse konfiguriert leitet dann entsprechend über https weiter. Im aktuellen Setup funktioniert das auch alles super. Nun bau ich einw enig neu und möchte von meinem "domain namen" : hub.home also nextcloud.hub.home auf internal nur noch nextcloud.internal wechseln. Da ich leider wenig bis gar keine Docs ehr über die damlige Erstellung habe (glaube lief über OPNsense direkt) fange ich von vorne an. ChatGPT hilft sheinbar auch nur beding.

So erstelle ich das Cert incl. root CA

openssl genrsa -out internal-services-ca.key 4096
openssl req -x509 -new -nodes -key internal-services-ca.key -sha512 -days 720 -out internal-services-ca.crt

# Input
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:München
Locality Name (eg, city) []:München
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Internal Services CA
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Internal Services CA
Email Address []:InternalServicesCA@internal

openssl x509 -in internal-services-ca.crt -noout -text

openssl genrsa -out internal-services.key 4096
openssl req -new -key internal-services.key -out internal-services.csr -config certificate.cfg

openssl x509 -req -in internal-services.csr -CA internal-services-ca.crt -CAkey internal-services-ca.key -CAcreateserial -out internal-services.crt -days 700 -sha512 -extfile certificate.cfg -extensions v3_req

openssl x509 -in internal-services.crt -noout -text

Im config file steht:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
CN = internal

[v3_req]
keyUsage = digitalSignature, keyEncipherment, nonRepudiation
extendedKeyUsage = serverAuth,clientAuth,1.3.6.1.5.5.8.2.2
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.internal

Was von außen identisch mit dem bisherigen Cert ist. Aber scheinbar liegt hier iregendwo der Fehler.

Das erstellte CA habe ich im Firefox und Brave eingetragen, analog zum bestehenden und funktionierenden.

Auf meinem AdGuardHome DNS das CA in /usr/share/ca-certificates abgelegt und für AdGuard selber das reguläre certificate incl. key unter /opt/AdGuard/ssl -> in AdGuard ist alles grün

Auf dem Nginx ebenfalls das CA in /usr/share/ca-certificates abgelegt und das reguläre certififcate unter /etc/nginx/ssl ebenso den key.

Auf beiden system natürlich

sudo update-ca-certificates
sudo dpkg-reconfigure ca-certificates

Dann neu gestartet. Auf meinem Desktop funktioniert beispielsweise ein wget https://adguard.internal ohne Probleme.

Im Firefox bekomme ich: SSL_ERROR_BAD_CERT_DOMAIN
-> Unable to communicate securely with peer: requested domain name does not match the server’s certificate.
HTTP Strict Transport Security: false
HTTP Public Key Pinning: false

und im Brave: NET::ERR_CERT_COMMON_NAME_INVALID

Langsam nervt es

und ich habe keine Ideen mehr.

Daher danke für euren Support!!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 91966034913

Url: https://administrator.de/contentid/91966034913

Ausgedruckt am: 19.12.2024 um 08:12 Uhr

10 Kommentare

Neuester Kommentar

Moin,

der Name mit dem du deinen Service aufrufst steht nicht im Zertifikat. Also ist das Zertifikat nicht für den Namen ausgestellt.

Der nötige Punkt heißt "common-Name".

Gruß
Spirit

Hmm. Den hab ich doch eigentlich im config file mit CN=internal angegeben. Dachte ich.

Ich möchte erreichen dass jeder Service wie z.B. Bitwarden.internal oder Nextcloud.internal aber eben auch neue die noch nicht vorhanden sind genutzt werden können, daher *.internal .

Wo mach ich da noch den Fehler?

Eine andere Frage. Muss es eigentlich
[alt_names]
DNS.1 = *.internal

Oder

[alt_names]
DNS = *.internal

Heißen?

Dein Eintrag mit *.internal ist gut gedacht. Allerdings stellt du hier meine ich kein Wildcard Zertifikat aus. Deswegen passt das nicht.
Wie genau man self signed eines erstellt habe ich gerade nicht im Kopf.

Ich vermute das hier einige Kollegen deutlich mehr Ahnung davon haben als ich. Deine Fehlermeldung weist jedenfalls auf ein missmatch hin.

Ok Jungs, Mädels, und alle anderen: Ich habe es gelöst, fall jemand über das Thema stolpert.

Zu definieren ist im conf file:

[req_distinguished_name]
CN = service.internal

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.service.internal
DNS.2 = service.internal

Ich habe durch Zufall gelesen, dass einfach nur *.internal nicht unterstützt wird, da es keine tld mit internal gibt (ganz kurz und nicht ausführlich) daher die Erwieterung auf *.service.internal. So geht es bei mir wie gewünscht.

Nabend,

ich steh grad vor der gleichen Thematik und hab grad noch ein paar Fragezeichen. Vielleicht könntest du mir hier kurz noch weiterhelfen:

Meine cert.cfg schaut folgendermaßen aus:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
CN = intern.blub

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.intern.blub
DNS.2 = intern.blub

Nun erzeuge ich das CA-Cert und das Key-File:

# openssl genrsa -out internal-services-ca.key 4096
# openssl req -x509 -new -nodes -key internal-services-ca.key -sha512 -days 720 -out internal-services-ca.crt
# openssl genrsa -out internal-services.key 4096

Wenn ich nun

# openssl req -new -key internal-services.key -out internal-services.csr -config cert.cfg

ausführe, erhalte ich die folgende Ausgabe:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.  
-----
intern.blub []:

Ich kann mit dem Begriff Distinguished Name (DN) nichts erhellendes anfangen. Leer lassen funktioniert nicht, dann bricht der Vorgang ab. Nutze ich jetzt hier z.B. nextcloud.intern.blub (also jeden Service einzeln erstellen) oder kann ich hier auch ein Wildcardbezeichnung wie z.B. *.intern.blub verwenden und das erstellte SSL-Zertifikat dann für alle internen Dienste als Wildcard-Zertifikat nutzen? Mein Ziel ist es, die intern genutzten SSL Zertifkate für div. VM's (nextcloud, vaultwarden, bookstack ...) zu erstellen und den pflegenden Aufwand in meinem Heimnetzwerk zu reduzieren.

Danke und Grüße
I.

EDIT: Der Fehler wird durch den CN Eintrag in der cert.cfg verursacht. Was gehört hier am sinnvollsten rein?

hatte ich auch. Ich kann dir keine genauen Hintergründe geben, aber zwei Lösungen die bei mi geholfen haben.

1. einfach noch mal intern.blub eingeben (ich nehme an hier soll der CN noch mal angeprüft werden?)
2. In deiner cfg folgende Änderung einfügen, dann erscheint der prompt nicht mehr.

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

Vielleicht hilft es.

Wäre aber in der Tat spannend zu wissen was es damit auf sich hat.

Nabend, danke für die schnelle Antwort. Hab's oben ergänzt. Der Command stört sich wohl am CN Eintrag in der conf. Mit prompt = no wird ja eigentlich nur die Meldung unterdrückt, die Zertifikate wurden bei einem Test erstellt. Wie machst du das in der Praxis? Hast du eine VM auf der du die rootCA und alle SSL Zertifikate erstellst und kopierst die jeweiligen SSL-Zertifikate dann in die einzelnen VM's? Nutzt du dann für jede VM, also jeden Service, ein eigenes SSL-Zertifikat oder ein selbsterzeugtes Wildcard?

Wie oben beschrieben erstelle ich das Wild card certificate für eine Domain. Überall dort wo es nötig ist wird es hinkopiert. Meist ist dies aber nicht nötig da ich vor all meinen Services einen Nginx als Reverse Proxy implementiert habe, jedenfalls für den Zugriff von Client (Desktop, Smartphone). Dieser hat entsprechend das certificate.

Auf den Clients brauchst du dann das Root CA damit dem Server certificate vertraut werden kann und auch die nervigen unprofessionellen Warnungen verschwinden.

Erstellen kannst du das Root ca certificate meines Wissens überall wo OpenSSL installiert ist. Entscheidend ist dann eher wo du die keys etc. aufbewahrst.