Fritzbox will Passwort für Zertifikat

[Pummeluff]

Guten Abend,

ich hab mich heute mal an Let's Encrypt rangewagt und mir ein Zertifikat erstellt. Jetzt wollte ich das Zertifikat testweise nutzen, um meine Fritzbox mal mit HTTPS auszustatten.

Gemäß dieser Anleitung hab ich dann die PEM-Zertifikate zusammengefasst.

cat privkey1.pem cert1.pem chain1.pem fullchain1.pem > fritz.pem

Wenn ich jetzt das Zertifikat versuch hochzuladen (Internet → Freigaben → FRITZ!Box-Dienste → Zertifikat → Benutzereigenes Zertifikat), bekomm ich die Meldung, dass das eingegebene Kennwort falsch sei. Eingegeben hab ich gar keins. Und Let's Encrypt hat gar kein Passwort.

Wie krieg ich das Zertifikat in meine Fritzbox rein?

 

[madmax2010]

hat gar kein Passwort.

hast du mal das, was die 1. Antwort sagt gemacht?
Also den Privatekey mit Passwort versehen und es dann probiert?

 

[Pummeluff]

Den Private Key hab ich von Let's Encrypt. Da hatte ich keine Möglichkeit, ein Passwort einzugeben.

 

[madmax2010]

Aber du kannst ein passwort setzen.
Wie hast du schon verlinkt.

 

[jo0]

Nutze doch einfach das Zertifikat von der Fritzbox? Dein Browser schlägt zwar Alarm, aber ob das signiert ist oder nicht, spielt eigentlich keine Rolle, weil es deine Hardware ist

 

[Pummeluff]

Nutze doch einfach das Zertifikat von der Fritzbox?

Der Hauptzweck war eigentlich, dass ich mich mal mit Let's Encrypt auseinandersetz.

Also den Privatekey mit Passwort versehen und es dann probiert?

openssl rsa -aes192 -in privkey1.pem -out privkey2.pem
Not an RSA key

Hab mal den Claude gefragt. Der hat geantwortet:

Das Problem liegt darin, dass die Fritzbox ein Zertifikat im PKCS#12-Format (.p12 oder .pfx Datei) erwartet, während Sie aktuell separate PEM-Dateien haben. Sie müssen Ihren privaten Schlüssel und das Zertifikat zunächst in das richtige Format konvertieren.
Hier sind die Schritte zur Konvertierung mit OpenSSL:

openssl pkcs12 -export -out fritzbox_cert.p12 -inkey private1.pem -in cert1.pem

Das klappt soweit auch. Nur beim Hochladen meckert die Fritzbox, dass das Zertifikat nicht gültig wär.

 

[gaym0r]

openssl rsa -aes192 -in privkey1.pem -out privkey2.pem
Not an RSA key

Wie hast du denn die Zertifikate genau erstellt? Mit Certbot ist es ein ECDSA Key und kein RSA.

 

[h00bi]

dass das eingegebene Kennwort falsch sei. Eingegeben hab ich gar keins. Und Let's Encrypt hat gar kein Passwort.

Es gibt einige Systeme, die ein Zertifikat ohne Passphrase (ist hier glaube ich der richtige Begriff) gar nicht akzeptieren. Bei der FB steht aber:

Sollte das Zertifikat kennwortgeschützt sein, geben Sie bitte auch das Kennwort an.

Davon abgesehen, dass du damit vielleicht nur ein bisschen rumspielen willst, solltest du das HTTPS Interface deiner Fritzbox ohne sinnvollen Grund nicht vom Internet erreichbar machen. Die Sicherheit des Webinterface war in den letzen 20 Jahren immer mal wieder löchrig.
Oder willst du das nur intern verwenden statt http?

Bedenke auch, dass du das LE Zertifkat dort alle 30 Tage manuell austauschen musst. LE wil sogar runter auf 6 Tage Gültigkeit.

 

[Helge01]

Für interne Geräte, worauf nur ich Zugriff habe, würde ich eher eine eigene CA aufbauen.

 

[prian]

Intern bei der FB würde einfach das den Browser als unsicher akzeptieren lassen.
Deutlich weniger Stress und keine Arbeit.

 

[Skudrinka]

an Let's Encrypt rangewagt und mir ein Zertifikat erstellt.

Erzähle doch mal, was überhaupt Ziel ist?

Tatsächlich die Tage ebenfalls mit Lets encrypt HTTPS ins Heimnetzwerk geholt.
Doch mit eigener Doamin und einem reverse proxy.
Lokal, ohne Port-Freigabe über einen Token.

 

[tollertyp]

Der Hauptzweck war eigentlich, dass ich mich mal mit Let's Encrypt auseinandersetz.

Frei nach dem Motto: Wenn man einen Hammer hat, sieht alles aus wie ein Nagel.

Also die erste Frage sollte immer sein: Stellt etwas eine Lösung für mein Problem dar, oder nicht.

 

[Pummeluff]

Hab's hinbekommen. Danke an gaym0r.

Wie hast du denn die Zertifikate genau erstellt? Mit Certbot ist es ein ECDSA Key und kein RSA.

certbot certonly --manual --preferred-challenges dns --key-type rsa --debug-challenges -d mydomain.v6.rocks -d \*.mydomain.v6.rocks

Und ja, dann erstellt der Certbot einen ecdsa-Key. Die Hilfe, die certbot ausgibt ist dabei nicht sonderlich hilfreich. Denn da steht nichts vom Key-Type.

Gefunden hab ich's dann hier.

Changing a certificate’s key type

Unless you are aware that you need to support very old HTTPS clients that are not supported by most sites, you can safely transition your site to use ECDSA keys instead of RSA keys.

If you want to change a single certificate to use ECDSA keys, you’ll need to create or renew a certificate while setting --key-type ecdsa on the command line:

Anscheinend besteht die Fritzbox noch auf rsa. Als ich den Parameter: --key-type rsa noch hinzugefügt hab, hat's dann funktioniert, ganz ohne Passwort.

Davon abgesehen, dass du damit vielleicht nur ein bisschen rumspielen willst, solltest du das HTTPS Interface deiner Fritzbox ohne sinnvollen Grund nicht vom Internet erreichbar machen.

Oh doch. Das hat mir schon einige Male die Haut gerettet, als das VPN aufgrund von DNS-Problemen nicht erreichbar war.

Bedenke auch, dass du das LE Zertifkat dort alle 30 Tage manuell austauschen musst.

Ja, ist mir bewusst. Allerdings muss ich mich mit dem Thema beruflich demnächst sowieso auseinandersetzen. Also wollte ich mal etwas Verständnis bei mir schaffen. Und das hab ich erreicht.

Die 30 Tage sehe ich nicht als Problem an. Mit dem RSA-Key hat auch das Fritzbox-Upload-Skript funktioniert. D.h. ich kann das per Cronjob immer zum Monatsanfang automatisiert machen lassen.

Für interne Geräte, worauf nur ich Zugriff habe, würde ich eher eine eigene CA aufbauen.

Hab ich auch mal gemacht. Bringt mir aber tatsächlich gar keinen Nutzen.

Frei nach dem Motto: Wenn man einen Hammer hat, sieht alles aus wie ein Nagel.

Find ich klasse, dass du Dir auch gern neues Wissen aneignen willst.

Was hab ich jetzt daraus gelernt:
Ich hab eine lokale Domain und eine DynDNS-Domain bei dynv6.com.

Damit hat sich das erste Problem ergeben. Die lokale Domain kann man nicht in die Optionen des Certbots mit reinpacken. Entsprechend ergeben sich dann im praktischen Fall für die Fritzbox die Konstellationen:

• Eigene CA: Fritzbox ist aus dem internen Netz mit gültigem Zertifikat erreichbar. Allerdings muss ich die CA auf allen Geräten verteilen, was bei den Smartphones etwas mühsam ist.
• Let's-Encrypt-Zertifikat: Fritzbox ist über die externe URL erreichbar. Allerdings bekomm ich die Zertifikatswarnung beim Zugriff über die interne URL.

Die logische Folge, sofern ich das "Problem" lösen wöllte, wäre die Umstellung der lokalen Domäne auf eine Subdomäne meiner DynDNS-Domain. Das macht die Sache aber wieder unbequem, da meine lokale Domain nur aus 3 Buchstaben besteht und die DynDNS-Domain ein ganzes Stück länger ist.

Will ich die Umstellung nicht und trotzdem meine lokale Domäne als SAN hinterlegen, könnte ich mir natürlich auch ein SAN-Zertifikat kaufen.

 

[h00bi]

Danke für die ausführliche Antwort und Verlinkung des Scripts.

Let's-Encrypt-Zertifikat: Fritzbox ist über die externe URL erreichbar. Allerdings bekomm ich die Zertifikatswarnung beim Zugriff über die interne URL.

dann hinterlege doch in deinem lokalen DNS externe.url.de -> IP der FB

 

[Pummeluff]

dann hinterlege doch in deinem lokalen DNS externe.url.de -> IP der FB

Das würde dann in die Richtung gehen, dass ich meine lokale Domain abschaff und durch eine Subdomain der DynDNS-Domain ersetz.

Nächster Schritt, nächstes Problem, nächster "Lernerfolg": Updates
Ich wollte jetzt mal die automatische Erneuerung des Zertifikats einrichten und sitz grad am Cronjob. Allerdings stoß ich dabei auf folgendes Problem:

certbot renew --cert-name mydomain.v6.rocks --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mydomain.v6.rocks.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Failed to renew certificate mydomain.v6.rocks with error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.')

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/mydomain.v6.rocks/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

Etwas Recherche brachte mich dann zu der Erkenntnis, dass Let's Encrypt wohl den TXT-Record im DNS bei jedem Renewal anpassen will. Dadurch wird mir jetzt auch die Bedeutung der DNS-Plugins für Certbot klar. Für dynv6.com gibt's kein Plugin, scheint aber mit nsupdate (dynv6.com) zu funktionieren.

Update
Claude meint, es gibt eine API bei Dynv6 und hat mir auch einen dynv6-dns-hook geschrieben:

Spoiler: dynv6-dns-hook.py

#!/usr/bin/env python3
import os
import sys
import time
import requests
from urllib.parse import quote

# Konfiguration
DYNV6_TOKEN = os.getenv('DYNV6_TOKEN')  # Token aus Umgebungsvariable
if not DYNV6_TOKEN:
    sys.exit("Fehler: DYNV6_TOKEN Umgebungsvariable nicht gesetzt")

DYNV6_API = "https://dynv6.com/api/v2"

def add_txt_record(domain, txt_name, txt_content):
    """
    Fügt einen TXT-Record hinzu
    """
    # Extrahiere den Challenge-Namen
    challenge_name = txt_name.replace(f".{domain}", "")
   
    # Erstelle den API-Endpoint
    url = f"{DYNV6_API}/zones/by-name/{domain}/records"
   
    # Bereite die Daten vor
    data = {
        "name": challenge_name,
        "type": "TXT",
        "data": txt_content,
        "ttl": 300
    }
   
    # Sende Request
    headers = {"Authorization": f"Bearer {DYNV6_TOKEN}"}
    response = requests.post(url, json=data, headers=headers)
   
    if response.status_code not in [200, 201]:
        sys.exit(f"Fehler beim Erstellen des TXT-Records: {response.text}")
   
    # Warte 30 Sekunden für die DNS-Propagation
    time.sleep(30)

def delete_txt_record(domain, txt_name, txt_content):
    """
    Löscht einen TXT-Record
    """
    # Extrahiere den Challenge-Namen
    challenge_name = txt_name.replace(f".{domain}", "")
   
    # Hole alle Records
    url = f"{DYNV6_API}/zones/by-name/{domain}/records"
    headers = {"Authorization": f"Bearer {DYNV6_TOKEN}"}
    response = requests.get(url, headers=headers)
   
    if response.status_code != 200:
        sys.exit(f"Fehler beim Abrufen der Records: {response.text}")
   
    # Finde den passenden Record
    records = response.json()
    for record in records:
        if (record["type"] == "TXT" and
            record["name"] == challenge_name and
            record["data"] == txt_content):
           
            # Lösche den Record
            delete_url = f"{DYNV6_API}/records/{record['id']}"
            delete_response = requests.delete(delete_url, headers=headers)
           
            if delete_response.status_code != 204:
                sys.exit(f"Fehler beim Löschen des TXT-Records: {delete_response.text}")
            return

def main():
    """
    Hauptfunktion zum Verarbeiten der certbot-Hooks
    """
    # Hole die Umgebungsvariablen von certbot
    action = os.getenv('CERTBOT_AUTH_OUTPUT')
    domain = os.getenv('CERTBOT_DOMAIN')
    validation = os.getenv('CERTBOT_VALIDATION')
   
    if action == "cleanup":
        delete_txt_record(domain, f"_acme-challenge.{domain}", validation)
    else:
        add_txt_record(domain, f"_acme-challenge.{domain}", validation)

if __name__ == "__main__":
    main()

Ich probier das später mal aus.

 

[prian]

Ich hatte ja angemerkt dass ich mir den Stress nicht machen würde, aber wenn Spieltrieb da ist und man was dabei vermutlich lernen kann, dann steht dem ja nichts im Wege.
Für einen vernünftigen Einsatz im eigenen Netz ist das fast schon Blödsinn sich den Stress zu machen, aus den anderen Gründen, warum nicht?

Das wollte ich nur noch nachschieben.