Hey, ich habs hinbekommen. Einfach mal an den Parametern in der CSR rumgeschraubt.
Erster, fehlerhafter CSR:
=====================
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
req_extensions = req_ext # The extentions to add to the self signed cert
[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = XX
localityName = XX
organizationName = BLUBB
commonName = www.meinedomain1.de
commonName_max = 64
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.meinedomain1.de
DNS.2 =www.meinedomain2.loc
DNS.3 = meinedomain3.com
DNS.4 = meindomain4.de
DNS.5 = fritz.box
==========================
Zweiter, erfolgreicher CSR:
==========================
[req]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = DE
ST = XX
L = XX
O = Blubb
OU = IT
CN = www.meinedomain1.de
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.meinedomain1.de
DNS.2 = fritz.box
DNS.3 = www.meinedomain2.loc
DNS.4 = meinedomain3.com
DNS.5 = meindomain4.de
===============================
Update:
Ich habe jetzt den eigentlichen Grund herausgefunden, warum es ein Problem mit dem ersten CSR gab. Die Zeile "commonName_max = 64" erzeugte einen Fehler in der Windows Openssl-Portierung, der dazu führte, dass der CN (CommonName) des Antragstellers leer blieb, der CSR aber trotzdem erzeugt wurde. Das ist mir lediglich nicht aufgefallen, weil das Feld Antragsteller (in den Windows-Zertifikatsbetrachter) dann mit der O (Organization) angezeigt wurde.
Die Fritzbox frisst dieses Zertifikat trotzdem, es hält aber dann wohl nicht der Verifizierung stand, die sie beim Reboot durchführt.
AVM hat dazu gemeint, dass sie evt. beim Import nun dieselben Checks implentieren könnten, wie beim Reboot, um solche Fehler transparenter dem Anwender mitzuteilen.
Danke für Eure Hilfe!
Erster, fehlerhafter CSR:
=====================
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
req_extensions = req_ext # The extentions to add to the self signed cert
[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = XX
localityName = XX
organizationName = BLUBB
commonName = www.meinedomain1.de
commonName_max = 64
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.meinedomain1.de
DNS.2 =www.meinedomain2.loc
DNS.3 = meinedomain3.com
DNS.4 = meindomain4.de
DNS.5 = fritz.box
==========================
Zweiter, erfolgreicher CSR:
==========================
[req]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = DE
ST = XX
L = XX
O = Blubb
OU = IT
CN = www.meinedomain1.de
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.meinedomain1.de
DNS.2 = fritz.box
DNS.3 = www.meinedomain2.loc
DNS.4 = meinedomain3.com
DNS.5 = meindomain4.de
===============================
Update:
Ich habe jetzt den eigentlichen Grund herausgefunden, warum es ein Problem mit dem ersten CSR gab. Die Zeile "commonName_max = 64" erzeugte einen Fehler in der Windows Openssl-Portierung, der dazu führte, dass der CN (CommonName) des Antragstellers leer blieb, der CSR aber trotzdem erzeugt wurde. Das ist mir lediglich nicht aufgefallen, weil das Feld Antragsteller (in den Windows-Zertifikatsbetrachter) dann mit der O (Organization) angezeigt wurde.
Die Fritzbox frisst dieses Zertifikat trotzdem, es hält aber dann wohl nicht der Verifizierung stand, die sie beim Reboot durchführt.
AVM hat dazu gemeint, dass sie evt. beim Import nun dieselben Checks implentieren könnten, wie beim Reboot, um solche Fehler transparenter dem Anwender mitzuteilen.
Danke für Eure Hilfe!
Zuletzt bearbeitet:
