Zeige Ergebnis 1 bis 3 von 3

Thema: Let's Encrypt - automatisiert für SF6

  1. #1
    STARFACE Admin

    Registriert seit
    04.03.2014
    Beiträge
    147

    Standard Let's Encrypt - automatisiert für SF6

    Let's Encrypt mit acme.sh und Bash - automatisiert für SF6.x

    So, mittlerweile habe ich es geschafft, automatisicert Let's Encrypt Zertifikate für meine SF zu bekommen.... ok, ich habe erst heute auf SF6 umgestellt.... aber dennoch funktioniert es.

    Voraussetzungen

    Ich benötige dazu:

    - acme.sh Client
    - DNS API
    - Bash

    acme.sh Client / DNS API

    Der offizielle LE Client war mir immer zu vollgeladen mit Tonnen von Python Abhängigkeiten. Ich habe dann den acme.sh Client kennengelenrt, welcher ein reines Shell Script ist (nicht einmal Bash, sondern Shell allgemein um grösstmögliche Kompatibilität zu gewähren). Das kam mir natürlich sehr entgegen, zumal der acme.sh Client auch noch das DNS-01 Challenge unterstützt. Wenn man also einen DNS Provider mit API hat, kann man sich mittles DNS-Einträgen Certs austellen lassen, ohne dass man auf dem jeweiligen Rechner etwas bewerkstelligen muss. Das ist natürlich von Vorteil, wenn bereits ein Webserver läuft, den man nicht ohne Weiteres benutzen kann oder wenn man Certs austellen will für Rechner, die nur im LAN erreichbar sind etc.

    Da ich ISPConfig benutze, habe ich Zugriff zu einer API gehabt (ab v.3.1 eine REST API) und so habe ich mir entsprechendes API Plugin geschrieben for acme.sh, welches inzwischen auch eingebunden ist. Somit ist das für mich also perfekt geeignet.

    Den acme.sh Client kann man sich hier besorgen: https://github.com/Neilpang/acme.sh

    WICHTIG: Anstelle des acme.sh Clients kann natürlich auch ein anderer Client verwendet werden. Dann müsste jedoch das Script an die Dateinamen etc. angepasst werden.

    DNS API

    Die ist an sich nur wichtig, wenn man nicht auf andere Weise sich die Certs generieren kann. Der acme.sh Client unterstützt DNS-01 Challenge und von dem her kann man sich das noch dazu basteln, wenn der eigene DNS Provider eine API zur Verfügung stellt. Hier ist eine Liste von DNS Provider resp. Control Panels, welche bereits von acme.sh unterstützt werden: https://github.com/Neilpang/acme.sh/tree/master/dnsapi

    In meinem Fall habe ich also folgendes benutzt, nachdem ich acme.sh installiert hatte, die entsprechend anpassen:
    Code:
    export ISPC_User="xxx"
    export ISPC_Password="xxx"
    export ISPC_Api="https://ispc.domain.tld:8080/remote/json.php"
    export ISPC_Api_Insecure=1
    
    acme.sh --issue --dns dns_ispconfig -d voip.domain.tld -d vpn-voip.domain.tld

    Bash

    Das nachfolgende Script habe ich unter Bash verfasst. Da dies standardmässig installiert ist, muss nichts weiteres gemacht werden auf SF6.

    Das Script

    Code:
    #!/usr/bin/env bash
    
    domain="voip.domain.tld"
    base="/root/.acme.sh/${domain}"
    
    #-----------------------------------------------------------------------------#
    #                                                                             #
    #                              BELOW BE DRAGONS                               #
    #                                                                             #
    #-----------------------------------------------------------------------------#
    
    p12="/tmp/sfcert.p12"
    keystore="/tmp/tomcat.keystore"
    web="/usr/share/tomcat6/ssl/"
    pass="changeit"
    
    # Create P12 file
    openssl pkcs12 -export -out ${p12} -inkey ${base}/${domain}.key -in ${base}/${domain}.cer -CAfile ${base}/fullchain.cer -caname root -name tomcat -password pass:${pass}
    
    # Create tomcat keystore
    keytool -importkeystore -deststorepass ${pass} -destkeypass ${pass} -destkeystore ${keystore} -srckeystore ${p12} -srcstoretype PKCS12 -srcstorepass ${pass} -alias tomcat
    
    # Replace orignal keystore with newly created one
    if [[ -f "${keystore}" ]]; then
        # Force move existing keystore
        mv -f "${web}/tomcat.keystore" "${web}/tomcat.keystore.orig"
        # Move newly created keystore into proper location
        mv "${keystore}" "${web}/"
        # Remove P12 file
        rm "${p12}"
        # Restart tomcat
        /etc/init.d/tomcat6 restart
    fi
    Das Script ist eigentlich relativ kurz. Wie gesagt, die Einstellung sind auf acme.sh getrimmt. Zuoberst die beiden Variablen anpassen. Also welche Domain verwendet worden ist und wo sich acme.sh befindet. Die restlichen Variablen können so belassen werden.

    Danach wird zuerst die P12 Datei mit dem Passwort "changeit" kreiert. Diese P12 Datei wird mit dem Keytool in einen entsprechenden Keystore umgewandelt. Schlussendlich überprüft das Script, ob der neue Keystore tatsächlich kreiert worden ist, falls ja, wird der bisherige Keystore umbenannt und der neu generierte Keystore wird an die entsprechende Stelle verschogen. Zulest wird noch die P12 Datei gelöscht und dann Tomcat neu gestartet.

    Soweit mir bekannt ist, dass das Passwort "changeit" nicht geändert werden, weil Tomcat in der Config Datei das Passwort benötigt um den Keystore zu öffnen. Ich habs aber nicht ausprobiert.

    Das Let's Encrypt Cert mittels Script und acme.sh installieren

    Nachdem wir nun ein LE Cert haben, das Script heruntergeladen, angepasst und ausführbar gemacht haben, fehlt nun noch der letzte Schritt: acme.sh mitzuteilen, wie er die LE Certs zu installieren hat. Dies geht einfach mit folgendem Befehl:

    Code:
    acme.sh --installcert -d voip.domain.tld --reloadcmd "/root/SCRIPTNAME.sh"
    That's It

    Damit sollte das nun automatisiert laufen. Einfach in 60 Tagen mal wieder reinschauen, ob es aktulisiert hat. Wieso nach 60 Tagen? Weil acme.sh die Zertifikate nach 60 Tagen versucht zu erneuern
    Geändert von hyanak (17.02.2017 um 14:32 Uhr)

  2. #2
    STARFACE Expert
    Benutzerbild von thomas.hertli
    Registriert seit
    30.05.2007
    Ort
    Arisdorf (CH)
    Beiträge
    937

    Standard

    Super danke!
    Da muss ich mich gleich mal in die Bastel-/Testecke setzen.

    Noch schöner wäre es, wenn STARFACE diese Funktionalität von Haus aus einbauen würde, wie dies einige Hostingprovider auch tun.
    STARFACE Certified Partner

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

    eMail: briefkasten ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, STARFACE-Telefonanlagen, Managed Services, Security

  3. #3
    STARFACE Admin

    Registriert seit
    04.03.2014
    Beiträge
    147

    Standard

    Von Haus ist nicht unbedingt einfach, wenn SF z.B. hinter NAT sitzt und nicht als öffentlicher Server zugänglich ist. Dadurch scheitert dann das Challenge mittels HTTP/S. Bei Hostingprovider, wo generell ein Webserver läuft und der Server nicht hinter NAT ist, ist es natürlich viel einfacher mittels Webroot-Variante Zertifikate zu holen.

    Ich benutze ISPConfig und habe halt für acme.sh das ISPC-DNS Plugin geschrieben.

    Das DNS-01 Challenge ist deswegen interessant, weil man unabhängig vom Server (vor hinter NAT, mit od. ohne laufenden Webserver etc.) ein Zertifikat bekommt. Man muss lediglich einen TXT Eintrag in die Zone machen, diesen prüfen lassen und danach kann man ihn wieder entfernen.

    Die Kunst ist, wie man das Cert auf die SF bekommt. Der Rest ist dann relativ simpel, wie du dem Script entnehmen kannst. Mit OpenSSL eine P12 Datei erstellen. Die P12 Datei dann in den Keystore umwandeln. Keystore an den richtigen Ort kopieren und Tomcat neu starten.
    Geändert von hyanak (17.02.2017 um 14:31 Uhr)

Ähnliche Themen

  1. Antworten: 10
    Letzter Beitrag: 11.09.2017, 09:23
  2. (Beta) Let's Encrypt Cert Helper (v38)
    Von DerGerät im Forum Module
    Antworten: 9
    Letzter Beitrag: 08.02.2017, 09:39
  3. HttpGetValue - Let's Encrypt SSL
    Von hyanak im Forum Modul-Designer
    Antworten: 3
    Letzter Beitrag: 27.04.2016, 09:10

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •