Hallo,
Bei mir hat die FBF7390 das Zertifikat bisher bei jedem Update, bei jedem Neustart behalten :mrgreen:
Bei mir hat die FBF7390 das Zertifikat bisher bei jedem Update, bei jedem Neustart behalten :mrgreen:
[HowTo] Eigenes Zertifikat für die Domäne bzw. die Fritz!Box Fernwartung
- Ersteller Smithy
- Erstellt am
Bei mir scheint die Box auch allgemein ne Meise zu haben. DECT funktioniert regelmäßig nicht mehr weswegen die Box dementsprechend häufig neugestartet werden muß.
Ist es auch möglich, das eigene Zertifikat irgendwie von Hand (telnet) auf eine Box zu bringen, für die es die 06.10 noch nicht gibt?
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,272
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ja, ist aber Fummelei und nichts, was in dieses Forum gehört. Wenn Du den Aufwand treiben willst, schreib mir eine PN.
Der private Schlüssel muß mit einem boxspezifischen Kennwort verschlüsselt sein, damit er beim Start akzeptiert wird. Ist es nicht möglich, mit diesem boxspezifischen Kennwort den Key zu öffnen, wird ein neuer generiert und damit war Dein Versuch dann vergebens. Der eigentliche Aufwand besteht also im Ermitteln dieses Kennworts oder man schiebt der Box den eigenen Key im Rahmen der erwähnten Generierung unter.
Alles nichts, was man öffentlich "breittreten" muß ... aber auch nicht unmöglich und da jede gesicherte Verbindung zu einer FRITZ!Box (und zur Sicherheit gehört eben auch die sichere Identität der Gegenstelle) ein Gewinn in meinen Augen ist, helfe ich gerne. Allerdings muß man sich vorher über den Aufwand im Klaren sein und mitten im Strom die Pferde zu wechseln, mag ich persönlich eher nicht ... also gilt für mich da: Wenn schon, denn schon ...
Allerdings hilft das auch nur für den HTTP-Zugriff, der FTP-Server generiert vor der 06.10 generell ein neues Zertifikat ... für den sicheren FTP-Zugriff hilft das also nicht weiter.
Wosign bietet ja schon seit einigen Wochen kostenlose Zertifikate an.
Vorteile ggü. Startssl: 2 Jahre gültig, multidomainfähig, man kann soviel Zertifikate haben wie man möchte (wenn man es zB verliert). Nachteil ist, dass man ca. 24h wartet, da es manuell geprüft wird.
Seit kurzem gibts den Bestellprozess auch auf englisch und kompakt auf einer Seite: https://buy.wosign.com/free/
Soeben in die Fritzbox importiert, funktioniert einwandfrei. Habe dabei das bundle "for nginx.zip" hergenommen; zuerst den Inhalt des Keyfiles und dann des Zertifikates in eine Textdatei kopiert, diese als .pem abgespeichert.
Vorteile ggü. Startssl: 2 Jahre gültig, multidomainfähig, man kann soviel Zertifikate haben wie man möchte (wenn man es zB verliert). Nachteil ist, dass man ca. 24h wartet, da es manuell geprüft wird.
Seit kurzem gibts den Bestellprozess auch auf englisch und kompakt auf einer Seite: https://buy.wosign.com/free/
Soeben in die Fritzbox importiert, funktioniert einwandfrei. Habe dabei das bundle "for nginx.zip" hergenommen; zuerst den Inhalt des Keyfiles und dann des Zertifikates in eine Textdatei kopiert, diese als .pem abgespeichert.
Zuletzt bearbeitet:
Habe mein AlphaSSL Zertifikat von domainfactory erfolgreich in meine Fritzbox 7390 importieren können. Vielen Dank für das HowTo!
Hi,
ich habe mir ein Zertifikat bei StartSSL für meine bei 1&1 gehostete subdomain.meinedomain.de erzeugt und nach dem HowTo in die Fritz!Box 7490 (Fritz!OS 6.24) erfolgreich importiert. Die subdomain.meinedomain.de hat als CNAME meindyndns.dd-dns.de eingetragen. Die Fritz!Box ist auf Port 5000 nach draußen freigegeben und dynDNS wird über twodns.de bereitgestellt.
Wenn ich nun per https://subdomain.meinedomain.de:5000 auf die Box zugreifen möchte, kann der Browser "keine Verbindung zur Website" herstellen. Getestet mit FF, Chrome, Opera. Auch https://meindyndns.dd-dns.de:5000 kann der Browser nicht finden. Ein ping auf subdomain.meinedomain.de antwortet mit der richtigen IPv4-Adresse.
Wenn ich das Zertifikat wieder aus der Fritz!Box lösche, dann kann ich mit beiden URIs auf die Box zugreifen. Ich habe jeweils nach dem Import, bzw. dem Löschen des Zertifikats die Box neu gestartet.
Kann mir jemand bei dem Problem helfen? Oder hat jemand ähnliche Erfahrungen?
Any help appreciated
Grüße Peter
ich habe mir ein Zertifikat bei StartSSL für meine bei 1&1 gehostete subdomain.meinedomain.de erzeugt und nach dem HowTo in die Fritz!Box 7490 (Fritz!OS 6.24) erfolgreich importiert. Die subdomain.meinedomain.de hat als CNAME meindyndns.dd-dns.de eingetragen. Die Fritz!Box ist auf Port 5000 nach draußen freigegeben und dynDNS wird über twodns.de bereitgestellt.
Wenn ich nun per https://subdomain.meinedomain.de:5000 auf die Box zugreifen möchte, kann der Browser "keine Verbindung zur Website" herstellen. Getestet mit FF, Chrome, Opera. Auch https://meindyndns.dd-dns.de:5000 kann der Browser nicht finden. Ein ping auf subdomain.meinedomain.de antwortet mit der richtigen IPv4-Adresse.
Wenn ich das Zertifikat wieder aus der Fritz!Box lösche, dann kann ich mit beiden URIs auf die Box zugreifen. Ich habe jeweils nach dem Import, bzw. dem Löschen des Zertifikats die Box neu gestartet.
Kann mir jemand bei dem Problem helfen? Oder hat jemand ähnliche Erfahrungen?
Any help appreciated
Grüße Peter
Zuletzt bearbeitet:
Hallo Frank_m27, die Kopfschmerzen hatte ich auch und sie nur mit dem "Hammer" gelöst. Meine Fritz!Box nutzt aber nun das Zertifikat von StartCom und damit ist mein Ziel erreicht.
Nutze unbedingt den IE (mag ich auch nicht). Ich gehe davon aus, dass Du den "Validations Wizard" erfolgreich absolviert hast, dann "Certificates Wizard" u. "Web Server SSl/TLS Certificate" wählen, hier den Host eintragen und die Option "Generated by IE Browser to get .PFX format certificate" wählen. Nun die Webzugriffsbestätigung des IE's mit Ja bestätigen. Es folgt die Abfrage nach "CSP Selection" und "Key length" (ich habe die Vorgaben so belassen). Dann auf "submit" klicken - das erforderliche Zertifikat wird in Deinen IE gefrickelt.
Du rufst die Einstellungen des IE auf, dort auf "Inhalte" und "Zertifikate". Unter "Eigene Zertifikate" exportierst Du nun das entsprechende Zertifikat mit privatem Schlüssel!!! (also "Ja, privaten Schlüssel exportieren" wählen) als PKCS #12 (.pfx) (geht vermutlich auch nicht in einem anderen Format).
Nun brauchen wir für die FRITZ!Box ja eine .PEM-Datei, die habe ich bei https://www.sslshopper.com/ssl-converter.html entsprechend konvertiert. Die konvertierte .PEM auf die FRITZ!Box laden und ... was soll ich sagen... funzt
Ach ja, das beim Export des Zertifikats vom IE verwendete Kennwort auch bei der Konvertierung und beim Laden auf die FRITZ!Box nutzen!
Nutze unbedingt den IE (mag ich auch nicht). Ich gehe davon aus, dass Du den "Validations Wizard" erfolgreich absolviert hast, dann "Certificates Wizard" u. "Web Server SSl/TLS Certificate" wählen, hier den Host eintragen und die Option "Generated by IE Browser to get .PFX format certificate" wählen. Nun die Webzugriffsbestätigung des IE's mit Ja bestätigen. Es folgt die Abfrage nach "CSP Selection" und "Key length" (ich habe die Vorgaben so belassen). Dann auf "submit" klicken - das erforderliche Zertifikat wird in Deinen IE gefrickelt.
Du rufst die Einstellungen des IE auf, dort auf "Inhalte" und "Zertifikate". Unter "Eigene Zertifikate" exportierst Du nun das entsprechende Zertifikat mit privatem Schlüssel!!! (also "Ja, privaten Schlüssel exportieren" wählen) als PKCS #12 (.pfx) (geht vermutlich auch nicht in einem anderen Format).
Nun brauchen wir für die FRITZ!Box ja eine .PEM-Datei, die habe ich bei https://www.sslshopper.com/ssl-converter.html entsprechend konvertiert. Die konvertierte .PEM auf die FRITZ!Box laden und ... was soll ich sagen... funzt
Ach ja, das beim Export des Zertifikats vom IE verwendete Kennwort auch bei der Konvertierung und beim Laden auf die FRITZ!Box nutzen!
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,272
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
So nett es auch sein mag, daß das hinterher mit diesem Zertifikat funktioniert ... das ist ein Weg, von dem man nur ganz dringend abraten kann und das macht sogar der Betreiber von sslshopper.com:
Schon der Upload der PKCS12-Datei in Kombination mit dem Kennwort zum Entschlüsseln ist ein "epic fail" ... das sollte man höchsten dann in Erwägung ziehen, wenn man das Zertifikat inkl. des zertifizierten RSA-Keys ohnehin innerhalb der nächsten 30 Minuten entsorgen will.https://www.sslshopper.com/ssl-converter.html schrieb:
Man gibt einfach den privaten Teil eines RSA-Schlüssels niemals aus der Hand bzw. sichert und exportiert ihn nur in verschlüsselter Form. Wenn man dann jemandem sowohl diese Datei als auch das verwendete Kennwort übergibt, ist dieses Schlüsselpaar "verbrannt".
Hallo,
also ich hab bei meiner 7560 auch das Problem, dass das Zertifikat bei Neustart wieder weg ist. Auch der AVM-Support konnte mir nicht weiterhelfen.
Ist es vielleicht so, dass ich in jedem Fall, den privaten Key mit RSA verschlüsseln MUSS, um es dann bei Import dieses Kennwort im WF anzugeben? Das habe ich noch nicht ausprobiert. Es wird auch nicht explizit drauf hingewiesen...
also ich hab bei meiner 7560 auch das Problem, dass das Zertifikat bei Neustart wieder weg ist. Auch der AVM-Support konnte mir nicht weiterhelfen.
Ist es vielleicht so, dass ich in jedem Fall, den privaten Key mit RSA verschlüsseln MUSS, um es dann bei Import dieses Kennwort im WF anzugeben? Das habe ich noch nicht ausprobiert. Es wird auch nicht explizit drauf hingewiesen...
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,272
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Hast Du irgendwie am Urlader-Environment herumgespielt nach dem Import?
Der private Schlüssel wird beim Import von der Box mit einem Kennwort gesichert und das leitet sich aus "maca" im Urlader-Environment her. Das muß zum Zeitpunkt der Speicherung also dieselbe MAC-Adresse sein wie beim Start des "ctlmgr". Zumindest früher generierte die Box dann zu diesem Zeitpunkt einen neuen Schlüssel, wenn sich der gespeicherte nicht öffnen ließ.
Zumindest bei der 7580 mit 06.54 hatte ich es noch überprüft, daß dort genau derselbe Algorithmus auf Basis der "maca"-Angabe für dieses Kennwort verwendet wird - das müßte also bei der 7560 auch so sein und von der OS-Version sollte es ohnehin nicht abhängen, sonst gibt's Chaos bei Updates.
Es spielt jedenfalls keine Rolle, ob der Key beim Upload in die Box mit einem Kennwort gesichert ist oder nicht (wobei man das Kennwort natürlich kennen muß, wenn es vorhanden ist und man Key + Zertifikat importieren will) - das wird ohnehin entschlüsselt und mit dem Geräte-Kennwort neu verschlüsselt.
MIt einem Shell-Zugang könnte man dann weiter untersuchen (z.B. /proc/tffs_stat ansehen, ob da ein Schreibzugriff erfolgt), was beim Upload des Keys schiefgehen soll.
Der private Schlüssel wird beim Import von der Box mit einem Kennwort gesichert und das leitet sich aus "maca" im Urlader-Environment her. Das muß zum Zeitpunkt der Speicherung also dieselbe MAC-Adresse sein wie beim Start des "ctlmgr". Zumindest früher generierte die Box dann zu diesem Zeitpunkt einen neuen Schlüssel, wenn sich der gespeicherte nicht öffnen ließ.
Zumindest bei der 7580 mit 06.54 hatte ich es noch überprüft, daß dort genau derselbe Algorithmus auf Basis der "maca"-Angabe für dieses Kennwort verwendet wird - das müßte also bei der 7560 auch so sein und von der OS-Version sollte es ohnehin nicht abhängen, sonst gibt's Chaos bei Updates.
Es spielt jedenfalls keine Rolle, ob der Key beim Upload in die Box mit einem Kennwort gesichert ist oder nicht (wobei man das Kennwort natürlich kennen muß, wenn es vorhanden ist und man Key + Zertifikat importieren will) - das wird ohnehin entschlüsselt und mit dem Geräte-Kennwort neu verschlüsselt.
MIt einem Shell-Zugang könnte man dann weiter untersuchen (z.B. /proc/tffs_stat ansehen, ob da ein Schreibzugriff erfolgt), was beim Upload des Keys schiefgehen soll.
Ehrlich gesagt, das einzig geänderte war ein Rebranding auf AVM, (quote SETENV firmware_version avm) da ich den Provider auf T-online gewechselt habe. Das kann es aber nicht sein, da der AVM-Support das Verhalten mit meinen Zert. nachstellen konnte. So wurde verwiesen auf das Zert. als Verursacher, man könne aber nicht sagen, was genau.
Das Zertifikat stammt aus meiner Windows-CA. Ich hab auch schon probiert, die CA selbst in die Keychain zu hinterlegen. Das war es auch nicht.
Ist der Zugang auf die Shell-Ebene ohne weiteres möglich? Muss ich mal googlen!! Danke!
Das Zertifikat stammt aus meiner Windows-CA. Ich hab auch schon probiert, die CA selbst in die Keychain zu hinterlegen. Das war es auch nicht.
Ist der Zugang auf die Shell-Ebene ohne weiteres möglich? Muss ich mal googlen!! Danke!
tester25
Aktives Mitglied
- Mitglied seit
- 23 Feb 2010
- Beiträge
- 823
- Punkte für Reaktionen
- 26
- Punkte
- 28
Ist zwar lange her, aber vielleicht kannst du mir sagen, wie ich das Zertifikat von DomainFactory ins entsprechende Format bekomme, um es für die FRITZ!Box vorzubereiten? Danke und Gruß, tester25
Ich muss gestehen, dass ich nicht mehr weiß wie ich es 2015 gemacht habe, aber folgender Weg funktioniert, auch wenn es sicherlich noch einfacher geht.
Diese Anleitung bezieht sich auf ein AlphaSSL Zertifikat von DomainFactory, welches aus drei Teilen besteht - domain.crt, domain.key und Intermediate_CA_Bundle.crt.
FritzBox 7390 mit FRITZ!OS: 06.83 Installiert am: 01.04.2017.
Die FritzBox benötigt eine .pem Datei, die alle drei Teile enthält. Die drei Teile von DF liegen bereits im PEM Format vor (---BEGIN--- ---END--- im Editor, nichts kryptisches).
Es reicht also vermutlich wie in den alten Beiträgen erklärt, diese aneinander zu reihen. Allerdings haut das bei mir Stand heute NICHT hin. Vielleicht mache ich was falsch, falsche Reihenfolge, Zeilenumbrüche, Editor Codierung etc pp.
Ich habe deshalb zwei Konvertierungen mit OpenSSL vorgenommen. Zuerst ins PKCS12 Format zum verschmelzen der drei Teile und dann wieder zurück zu PEM. Dazu wird natürlich OpenSSL benötigt, geht bestimmt auch unter Windows, dazu bitte Google fragen. Ich habs unter Linux nachinstalliert, das geht zB unter Ubuntu mit apt-get install openssl oder unter openSUSE mit zypper in openssl.
Die Befehle zur Umwandlung lauten dann:
Es folgt eine Passworteingabe, die das zwischenschritt.p12 schützen soll. Also etwas einfaches einegeben, wie "test".
Wir haben nun ein kryptisches P12 Zertifikat, das alle drei Teile enthält, aber wieder zurück zum PEM Format muss. Dazu:
Es folgt die Passwortabfrage für das P12, in meinem Fall "test".
Danach KANN man ein Passwort für die PEM Datei vergeben, ich habe es leer gelassen und einfach Enter gedrückt.
Nun haben wir mit der fritzbox.pem Datei ein Zertifikat das in die FritzBox über die Admin Oberfläche importiert werden kann. Ggf muss dort das Passwort für die PEM Datei eingegeben werden, wenn man im Schritt zuvor eines vergeben hat, in meinem Fall bleibt das Feld leer.
Ich hoffe das haut hin, bei mir hat's gerade genau so geklappt. Die finale fritzbox.pem hat übrigens ein paar zusätzliche Angaben und sieht wie folgt aus:
Zuletzt bearbeitet:
smartie
Mitglied
- Mitglied seit
- 30 Mrz 2005
- Beiträge
- 520
- Punkte für Reaktionen
- 21
- Punkte
- 18
Hallo zusammen,
witzerigerweise wollte ich genau diese Frage stellen (habe mein Zertifikt soagar auch von DF).
Die Anleitung ist gut, ich habe zwar das Intermediate-Zertifikat als .pem Datei, aber auch damit hat es genau wie beschrieben funktioniert!
Vielen Dank für die Unterstützung, ich hatte schon bei AVM angefragt, aber sie haben nur auf die Import-Anleitung verwiesen und konnten sonst KEINE Hilfestellung geben (fand ich schade).
Danke noch mal, das hat mir echt sehr geholfen!!!!
witzerigerweise wollte ich genau diese Frage stellen (habe mein Zertifikt soagar auch von DF).
Die Anleitung ist gut, ich habe zwar das Intermediate-Zertifikat als .pem Datei, aber auch damit hat es genau wie beschrieben funktioniert!
Vielen Dank für die Unterstützung, ich hatte schon bei AVM angefragt, aber sie haben nur auf die Import-Anleitung verwiesen und konnten sonst KEINE Hilfestellung geben (fand ich schade).
Danke noch mal, das hat mir echt sehr geholfen!!!!
Zuletzt bearbeitet:
Hi,
also ich bin den Weg jetzt auch mal gegangen. Openssl hat problemlos das Zertifikat aus dem P12-Format zurückkonvertiert, und ich hab das in die FB7560 geladen. Alles funktioniert wie vorher, exakt bis zum Reboot. Dann alles empty, FB hat ein neues Zert. erstellt. Da AVM das an meiner FB nachstellen konnte, nehme ich an das es ein Firmware-Bug (6.83) sein muss, dass es keinen Reboot überlebt.
Also bevor jmd. graue Haare bekommt, auf ein Update warten....
also ich bin den Weg jetzt auch mal gegangen. Openssl hat problemlos das Zertifikat aus dem P12-Format zurückkonvertiert, und ich hab das in die FB7560 geladen. Alles funktioniert wie vorher, exakt bis zum Reboot. Dann alles empty, FB hat ein neues Zert. erstellt. Da AVM das an meiner FB nachstellen konnte, nehme ich an das es ein Firmware-Bug (6.83) sein muss, dass es keinen Reboot überlebt.
Also bevor jmd. graue Haare bekommt, auf ein Update warten....
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,272
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Wenn das ein Problem der 06.83 sein sollte, tritt es aber bei der 7580 nicht auf ... ich habe gerade bei einer solchen das Zertifikat aus diesem Thread importiert und das ist auch nach einem Neustart der Box immer noch vorhanden.
Auch der Weg zur Berechnung des Kennworts für die Verschlüsselung der "websrv_ssl_key.pem" hat sich (für die 7580) nicht geändert.
Entweder das hängt damit zusammen, daß da noch irgendwelche Ketten bis zu einer CA in der Import-Datei vorhanden sind oder es ist noch irgendetwas vollkommen anderes ... wie genau hat AVM das denn nachstellen können?
Übersteht denn das o.a. Zertifikat den Import und einen Neustart (hinterher nicht vergessen, es wieder zu löschen)?
Bei der 7560/7580 werden zwar die Nodes für das TFFS an einer anderen Stelle angelegt (in der /etc/init.d/S08-tffs und nicht in der /etc/init.d/S01-head, wie z.B. bei der 7490), aber sie werden angelegt und damit ist (zumindest theoretisch) eigentlich auch die Variante vom Tisch, daß da ein "regular file" angelegt wird und die Daten damit nicht im TFFS landen (wo dann das "Verschwinden" beim nächsten Start wieder normal wäre).
Haben denn wirklich noch andere 7560-Besitzer das Problem mit diesem "Verschwinden" des importierten Zertifikats nach einem Neustart?
Wenn ich zurücklese in diesem Thread, ist das bisher ja "nur" @donald24 ... und - anders als von AVM "angedacht" - es wird hier eine Windows-CA verwendet. Da könnte dann schon die Kette der Zertifikate bis zur CA und/oder irgendein "komisches" Flag im Zertifikat dafür sorgen, daß ein Zertifikat einer Windows-CA nicht problemlos akzeptiert wird bzw. bei der "Prüfung" beim nächsten Neustart durchfällt (und dann wird ein neues erzeugt) - deshalb der "Kreuztest" mit dem anderen Zertifikat, das ganz simpel mit OpenSSL als "self-signed certificate" erstellt wurde (wobei ich auch mit Zertifikaten von der eigenen CA (allerdings ist auch diese OpenSSL-basiert) keine Probleme habe bei 7390, 7490, 7412, 6490 und 7580).
Auch der Weg zur Berechnung des Kennworts für die Verschlüsselung der "websrv_ssl_key.pem" hat sich (für die 7580) nicht geändert.
Entweder das hängt damit zusammen, daß da noch irgendwelche Ketten bis zu einer CA in der Import-Datei vorhanden sind oder es ist noch irgendetwas vollkommen anderes ... wie genau hat AVM das denn nachstellen können?
Übersteht denn das o.a. Zertifikat den Import und einen Neustart (hinterher nicht vergessen, es wieder zu löschen)?
Bei der 7560/7580 werden zwar die Nodes für das TFFS an einer anderen Stelle angelegt (in der /etc/init.d/S08-tffs und nicht in der /etc/init.d/S01-head, wie z.B. bei der 7490), aber sie werden angelegt und damit ist (zumindest theoretisch) eigentlich auch die Variante vom Tisch, daß da ein "regular file" angelegt wird und die Daten damit nicht im TFFS landen (wo dann das "Verschwinden" beim nächsten Start wieder normal wäre).
Haben denn wirklich noch andere 7560-Besitzer das Problem mit diesem "Verschwinden" des importierten Zertifikats nach einem Neustart?
Wenn ich zurücklese in diesem Thread, ist das bisher ja "nur" @donald24 ... und - anders als von AVM "angedacht" - es wird hier eine Windows-CA verwendet. Da könnte dann schon die Kette der Zertifikate bis zur CA und/oder irgendein "komisches" Flag im Zertifikat dafür sorgen, daß ein Zertifikat einer Windows-CA nicht problemlos akzeptiert wird bzw. bei der "Prüfung" beim nächsten Neustart durchfällt (und dann wird ein neues erzeugt) - deshalb der "Kreuztest" mit dem anderen Zertifikat, das ganz simpel mit OpenSSL als "self-signed certificate" erstellt wurde (wobei ich auch mit Zertifikaten von der eigenen CA (allerdings ist auch diese OpenSSL-basiert) keine Probleme habe bei 7390, 7490, 7412, 6490 und 7580).
Danke für die Nachricht. Konnte soeben nachstellen, dass das dummy.cert erfolgreich einen Reboot überlebt. Jetzt bin ich baff.
Dann wirds wohl an meiner CA liegen, diese ist aber standardkonform dem Webserver-Template gefolgt und hat bei noch keinem Device gezickt.
Ich mache morgen mal ein neues Zertifikat, dass keine Rückschlüsse auf meine Web-Domain zuläßt und lade es hier hoch. Wäre toll wenn jmd. den Auslöser findet.
sry, dateiupload funktioniert nicht:
-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgITFwAABVZHxSsUL9YEWwABAAAFVjANBgkqhkiG9w0BAQsF
ADBRMRMwEQYKCZImiZPyLGQBGRYDbG9jMRswGQYKCZImiZPyLGQBGRYLZW50ZW5o
YXVzZW4xHTAbBgNVBAMTFGVudGVuaGF1c2VuLVZTOFIyLUNBMB4XDTE3MDYyMDE5
MzczNFoXDTE5MDYyMDE5MzczNFowRjELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJh
ZGVuLVd1ZXJ0dGVtYmVyZzELMAkGA1UEBxMCRk4xDTALBgNVBAoTBHRlc3QwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3YMEvzXUxwdQwhhLlQzEDSbHZ
7kRyIp5eqSH8o5Vdd0OQvza2/VKuTSxf4gcl/dsQ/fiOKLUC3I3At5Yd1odVY7qm
nl/AlquZa2jVrobJeQH+3yIDMaVP2P7xn2m2DB0pDusAQHMiq2wDbftNHyOY50pi
pnvenqvdsHkG5/q05huWp6Du9vheRFqvERe94TFilJ27Avc8Zr2sQPC/YSt+sao3
YhrGWp26HQOa2Wg5EgPwUp468WbSHQ/gY/Pf72KW2B7q/f+NEW8GECAYSHGYf7LV
i9/GwyzQw8BqVMxLe1OxTRcsy5YiBcObLk0CvV6Dd4Z68rY1QEbnYNF5BKdZAgMB
AAGjggJFMIICQTAUBgNVHREEDTALgglmcml0ei5ib3gwHQYDVR0OBBYEFM/D7Nsu
MHen0jxzxZEoktE/QVyGMB8GA1UdIwQYMBaAFELxXl93fALZuppFIsngeMJSRoOA
MIHTBgNVHR8EgcswgcgwgcWggcKggb+GgbxsZGFwOi8vL0NOPWVudGVuaGF1c2Vu
LVZTOFIyLUNBLENOPVZTMTIsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZp
Y2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZW50ZW5oYXVzZW4s
REM9bG9jP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFz
cz1jUkxEaXN0cmlidXRpb25Qb2ludDCBygYIKwYBBQUHAQEEgb0wgbowgbcGCCsG
AQUFBzAChoGqbGRhcDovLy9DTj1lbnRlbmhhdXNlbi1WUzhSMi1DQSxDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln
dXJhdGlvbixEQz1lbnRlbmhhdXNlbixEQz1sb2M/Y0FDZXJ0aWZpY2F0ZT9iYXNl
P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwIQYJKwYBBAGCNxQC
BBQeEgBXAGUAYgBTAGUAcgB2AGUAcjAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBALAcIvDw78a736WVjbRdkqet
mx4unsOpEyvvBtBpI9jKQIK7V6YKvUxHaqRmjVjpDIbLnYQV8qW+JtTGL/Kdd7Cy
N+pnrcDzDwKtdex+lstWeM9p+ctuHKld9T6Lo8QCWBrX1+stvQihustflIkjlRwQ
LITY/u0ff8fs7bv+/rzbkNE58kCfHNnC+feYqBYA1KIeYelHc7EIzW58x2hJ6Vq/
+DGqR+MKpXkD5IXE+8/81FnoJMowa6A8rW7YQv1AXrZSE/0uIIXoL2X11S0SFoSN
R6vctomaIkFv/qUtL4BwQw0olNSWyiZKnBIRZ+l7HwajW7rhy3KMyg4dsNa4BYY=
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC3YMEvzXUxwdQw
hhLlQzEDSbHZ7kRyIp5eqSH8o5Vdd0OQvza2/VKuTSxf4gcl/dsQ/fiOKLUC3I3A
t5Yd1odVY7qmnl/AlquZa2jVrobJeQH+3yIDMaVP2P7xn2m2DB0pDusAQHMiq2wD
bftNHyOY50pipnvenqvdsHkG5/q05huWp6Du9vheRFqvERe94TFilJ27Avc8Zr2s
QPC/YSt+sao3YhrGWp26HQOa2Wg5EgPwUp468WbSHQ/gY/Pf72KW2B7q/f+NEW8G
ECAYSHGYf7LVi9/GwyzQw8BqVMxLe1OxTRcsy5YiBcObLk0CvV6Dd4Z68rY1QEbn
YNF5BKdZAgMBAAECggEAeFWXsETFCPfGxGjW8XdcLGopuXbvl248OqYGVYELPSBM
SCoSP5aQsSyXV/w88KNbJBVlC/SOg+gzZSmT6tSiTlh5XWlEMF8vECg5zS8P6Bnu
Q1AtQ6dKcdFVyzzu47WjVRQjBjFE3JVc9gswA3XRqD7uwzm4w2egJIPvh6anEBlq
fRXX1jGeD9wRbjD7VKFGMzBXR7Gf2KJWlsmT4+thhRuJ4JyE2JRtPp8fid0kmmDI
A6U0CBvUWVKnD9h1mbpD7gCfTeGhvwTZYaxUkKZgG/N7znygTeUDF5mF2VVr1uKH
8oxFYLQ2oAZhpUJ4P7Cnl373mTPPbN7rVNQ2qrbiuQKBgQDu4/WQtyrEKHyFKa93
L/2pUtJutxFRm0PeQca+fHfJYWTHhDXMOaPvd/oCyHkgr1ZSMSW66roEmSPRKffA
uIOddvtzbC8hUrg2QaY4AV1PTqCvfD2kHJFYm/UYS53xXF5wcMYBCzvkXMqEzSQT
16QunDq/BP9VrzydFC3Adv0W6wKBgQDEgvoh9OerASJwD/f7dCJNo7DVtqMocYmk
3uwXJ+04WQLXLLZK7IUesqPINMT71cCVx1XL6V39adO6oc41KjUmhS9SG3Pgwoem
bIrSyPsPCST1UApqafUnUEr/xhJXMCAlEfPp01uTsjl8PQhSRpUXC0iMB0U/BJPi
F0zzm7GxywKBgQDouu7WoIuqdKLy/Cx0Wi2ukwBtWi4mKbRRyBT+KLZuW1LaSQQ8
RP9f4auQoIvY+tiG1Fiko967chIByPgUKe4XLv5DcWbs+PB78zMjJrkn9Tr4G3rV
8frrr2x00d46cLmUo1lTVQVxMbEe9deq+Q97VTqqNA0pBcJwaWM1OPbSJwKBgCIH
oHNC6t9lGeaYDVSBHvOc9iF8ODLnvnNLm0zDQEQyvdgvSP4eiUrwmoYwBTCrKmeF
lmjyZ7Fboyu9m2z/eybJh5FLabyxUzZRs5Se80L+TWUh0DvvT2HYeLRkQ4bPsbFZ
s4h5bnFcOrI2C3vb9zN/Y7fEBozMKSPM7yl8e8ATAoGBAIypaAF9Lr5W67BQWMcV
zXvhyENHF2/zQlPYQ3j3IcQakdChGgYnJMmzWty/35km2rwVvxsWGhukaCThR5G6
0GMtHd4V2uPqIRfSU4iYhsuFx7jQd+FDwWXrkHuX8izUk0Tkr9nI+6Rbq2DEKWQo
jdGxHbRP8CajydedSPFMcbHu
-----END PRIVATE KEY-----
Zertifikat wurde nach Reboot wieder automatisch vernichtet
Danke und Gruß
Dann wirds wohl an meiner CA liegen, diese ist aber standardkonform dem Webserver-Template gefolgt und hat bei noch keinem Device gezickt.
Ich mache morgen mal ein neues Zertifikat, dass keine Rückschlüsse auf meine Web-Domain zuläßt und lade es hier hoch. Wäre toll wenn jmd. den Auslöser findet.
sry, dateiupload funktioniert nicht:
-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgITFwAABVZHxSsUL9YEWwABAAAFVjANBgkqhkiG9w0BAQsF
ADBRMRMwEQYKCZImiZPyLGQBGRYDbG9jMRswGQYKCZImiZPyLGQBGRYLZW50ZW5o
YXVzZW4xHTAbBgNVBAMTFGVudGVuaGF1c2VuLVZTOFIyLUNBMB4XDTE3MDYyMDE5
MzczNFoXDTE5MDYyMDE5MzczNFowRjELMAkGA1UEBhMCREUxGzAZBgNVBAgTEkJh
ZGVuLVd1ZXJ0dGVtYmVyZzELMAkGA1UEBxMCRk4xDTALBgNVBAoTBHRlc3QwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3YMEvzXUxwdQwhhLlQzEDSbHZ
7kRyIp5eqSH8o5Vdd0OQvza2/VKuTSxf4gcl/dsQ/fiOKLUC3I3At5Yd1odVY7qm
nl/AlquZa2jVrobJeQH+3yIDMaVP2P7xn2m2DB0pDusAQHMiq2wDbftNHyOY50pi
pnvenqvdsHkG5/q05huWp6Du9vheRFqvERe94TFilJ27Avc8Zr2sQPC/YSt+sao3
YhrGWp26HQOa2Wg5EgPwUp468WbSHQ/gY/Pf72KW2B7q/f+NEW8GECAYSHGYf7LV
i9/GwyzQw8BqVMxLe1OxTRcsy5YiBcObLk0CvV6Dd4Z68rY1QEbnYNF5BKdZAgMB
AAGjggJFMIICQTAUBgNVHREEDTALgglmcml0ei5ib3gwHQYDVR0OBBYEFM/D7Nsu
MHen0jxzxZEoktE/QVyGMB8GA1UdIwQYMBaAFELxXl93fALZuppFIsngeMJSRoOA
MIHTBgNVHR8EgcswgcgwgcWggcKggb+GgbxsZGFwOi8vL0NOPWVudGVuaGF1c2Vu
LVZTOFIyLUNBLENOPVZTMTIsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZp
Y2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZW50ZW5oYXVzZW4s
REM9bG9jP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFz
cz1jUkxEaXN0cmlidXRpb25Qb2ludDCBygYIKwYBBQUHAQEEgb0wgbowgbcGCCsG
AQUFBzAChoGqbGRhcDovLy9DTj1lbnRlbmhhdXNlbi1WUzhSMi1DQSxDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln
dXJhdGlvbixEQz1lbnRlbmhhdXNlbixEQz1sb2M/Y0FDZXJ0aWZpY2F0ZT9iYXNl
P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwIQYJKwYBBAGCNxQC
BBQeEgBXAGUAYgBTAGUAcgB2AGUAcjAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBALAcIvDw78a736WVjbRdkqet
mx4unsOpEyvvBtBpI9jKQIK7V6YKvUxHaqRmjVjpDIbLnYQV8qW+JtTGL/Kdd7Cy
N+pnrcDzDwKtdex+lstWeM9p+ctuHKld9T6Lo8QCWBrX1+stvQihustflIkjlRwQ
LITY/u0ff8fs7bv+/rzbkNE58kCfHNnC+feYqBYA1KIeYelHc7EIzW58x2hJ6Vq/
+DGqR+MKpXkD5IXE+8/81FnoJMowa6A8rW7YQv1AXrZSE/0uIIXoL2X11S0SFoSN
R6vctomaIkFv/qUtL4BwQw0olNSWyiZKnBIRZ+l7HwajW7rhy3KMyg4dsNa4BYY=
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC3YMEvzXUxwdQw
hhLlQzEDSbHZ7kRyIp5eqSH8o5Vdd0OQvza2/VKuTSxf4gcl/dsQ/fiOKLUC3I3A
t5Yd1odVY7qmnl/AlquZa2jVrobJeQH+3yIDMaVP2P7xn2m2DB0pDusAQHMiq2wD
bftNHyOY50pipnvenqvdsHkG5/q05huWp6Du9vheRFqvERe94TFilJ27Avc8Zr2s
QPC/YSt+sao3YhrGWp26HQOa2Wg5EgPwUp468WbSHQ/gY/Pf72KW2B7q/f+NEW8G
ECAYSHGYf7LVi9/GwyzQw8BqVMxLe1OxTRcsy5YiBcObLk0CvV6Dd4Z68rY1QEbn
YNF5BKdZAgMBAAECggEAeFWXsETFCPfGxGjW8XdcLGopuXbvl248OqYGVYELPSBM
SCoSP5aQsSyXV/w88KNbJBVlC/SOg+gzZSmT6tSiTlh5XWlEMF8vECg5zS8P6Bnu
Q1AtQ6dKcdFVyzzu47WjVRQjBjFE3JVc9gswA3XRqD7uwzm4w2egJIPvh6anEBlq
fRXX1jGeD9wRbjD7VKFGMzBXR7Gf2KJWlsmT4+thhRuJ4JyE2JRtPp8fid0kmmDI
A6U0CBvUWVKnD9h1mbpD7gCfTeGhvwTZYaxUkKZgG/N7znygTeUDF5mF2VVr1uKH
8oxFYLQ2oAZhpUJ4P7Cnl373mTPPbN7rVNQ2qrbiuQKBgQDu4/WQtyrEKHyFKa93
L/2pUtJutxFRm0PeQca+fHfJYWTHhDXMOaPvd/oCyHkgr1ZSMSW66roEmSPRKffA
uIOddvtzbC8hUrg2QaY4AV1PTqCvfD2kHJFYm/UYS53xXF5wcMYBCzvkXMqEzSQT
16QunDq/BP9VrzydFC3Adv0W6wKBgQDEgvoh9OerASJwD/f7dCJNo7DVtqMocYmk
3uwXJ+04WQLXLLZK7IUesqPINMT71cCVx1XL6V39adO6oc41KjUmhS9SG3Pgwoem
bIrSyPsPCST1UApqafUnUEr/xhJXMCAlEfPp01uTsjl8PQhSRpUXC0iMB0U/BJPi
F0zzm7GxywKBgQDouu7WoIuqdKLy/Cx0Wi2ukwBtWi4mKbRRyBT+KLZuW1LaSQQ8
RP9f4auQoIvY+tiG1Fiko967chIByPgUKe4XLv5DcWbs+PB78zMjJrkn9Tr4G3rV
8frrr2x00d46cLmUo1lTVQVxMbEe9deq+Q97VTqqNA0pBcJwaWM1OPbSJwKBgCIH
oHNC6t9lGeaYDVSBHvOc9iF8ODLnvnNLm0zDQEQyvdgvSP4eiUrwmoYwBTCrKmeF
lmjyZ7Fboyu9m2z/eybJh5FLabyxUzZRs5Se80L+TWUh0DvvT2HYeLRkQ4bPsbFZ
s4h5bnFcOrI2C3vb9zN/Y7fEBozMKSPM7yl8e8ATAoGBAIypaAF9Lr5W67BQWMcV
zXvhyENHF2/zQlPYQ3j3IcQakdChGgYnJMmzWty/35km2rwVvxsWGhukaCThR5G6
0GMtHd4V2uPqIRfSU4iYhsuFx7jQd+FDwWXrkHuX8izUk0Tkr9nI+6Rbq2DEKWQo
jdGxHbRP8CajydedSPFMcbHu
-----END PRIVATE KEY-----
Zertifikat wurde nach Reboot wieder automatisch vernichtet
Danke und Gruß
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,272
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich tippe mal auf die OID 1.3.6.1.4.1.311.20.2 (eine MS-OID, die wohl irgendwas mit einem Domain-Controller zu tun hat), die zu allem Überfluß wohl auch noch in UTF-16 kodiert ist (wobei ich das jetzt nicht mit asn1parse bis ins letzte Detail auseinandergenommen habe, das ist nur eine Schlußfolgerung aus der Anzeige des Wertes für diese x509v3-Extension).
Ist aber nur geraten ... ich habe nur das Zertifikat angesehen und bisher nicht versucht, das selbst mal zu importieren. Vielleicht morgen, wenn ich Zeit dafür finden sollte - wenn, dann will ich das auch "aufklären" und nicht nur konstatieren: geht oder geht nicht.
Ist aber nur geraten ... ich habe nur das Zertifikat angesehen und bisher nicht versucht, das selbst mal zu importieren. Vielleicht morgen, wenn ich Zeit dafür finden sollte - wenn, dann will ich das auch "aufklären" und nicht nur konstatieren: geht oder geht nicht.
Zuletzt bearbeitet:
Neueste Beiträge
-
AVM 6890 kein FW Update auf OS 8.0 ?- Letzte: NDiIPP
-
Fritzbox 7530 und 7412 via VPN (IPSec) verbinden (Vodafone DS-Lite & 1&1 IP4)- Letzte: 15Eleven_no7
-
6660 Cable Provider auslesen
- Letzte: NDiIPP
-
[Frage] Inhaus/Labor - Datenschutz - was wird übermittelt
- Letzte: NDiIPP
-
-
