Create LetsEncrypt SSL Via Certbot DNS Validation In Acme v02

Discussion in 'Tips/Tricks/Mods' started by ahrasis, May 6, 2018.

  1. ahrasis

    ahrasis Active Member

    Since certbot in Ubuntu 16.04 is upgraded to version 22, it is now ready to use Acme v2. I believe ISPConfig developers are already working on this but everybody have to be patient since it may not be out in the near future. As I am currently using CloudFlare as my dns server, I would like to share some tips/tricks that I recently did on my ubuntu nginx webserver in order to issue a Let's Encrypt wildcard SSL certs for one of my domains.

    Firstly, other than installing the default certbot via "apt -y install python-certbot-nginx", I have to install cloudflare plugin for it too. This I did by running "apt -y install python3-certbot-dns-cloudflare python3-cloudflare". This plugin is essential for this tip/trick.

    Secondly, I created a cloudflare credential file I named after my domain in /etc/letsencrypt folder running "nano /etc/letsencrypt/domain.tld.ini" and enter my cloudflare API and login email inside the file accordingly as follows:
    Code:
    # CloudFlare API key information
    dns_cloudflare_api_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    dns_cloudflare_email = [email protected]
    Thirdly, I modified default cli.ini file in the same folder running "nano /etc/letsencrypt/cli.ini" and add the above file and Acme v2 link inside (at its end) to ensure Acme v2 will be applied if the dns option is used when creating new Let's Encrypt SSL certs.
    Code:
    # Let's Encrypt site-wide configuration
    dns-cloudflare-credentials = /etc/letsencrypt/domain.tld.ini
    # Use the ACME v2 staging URI for testing things
    #server = https://acme-staging-v02.api.letsencrypt.org/directory
    # Production ACME v2 API endpoint
    server = https://acme-v02.api.letsencrypt.org/directory
    Finally, I run "certbot certonly -d domain.tld -d *.domain.tld --dns-cloudflare --agree-tos" to create Let's Encrypt wildcard SSL certs for my domain. This new certs will be defaulted to the same usual Let's Encrypt folder which you can manually use with ISPConfig. Its renewal file should look like this:
    Code:
    # renew_before_expiry = 30 days
    version = 0.22.0
    archive_dir = /etc/letsencrypt/archive/domain.tld
    cert = /etc/letsencrypt/live/domain.tld/cert.pem
    privkey = /etc/letsencrypt/live/domain.tld/privkey.pem
    chain = /etc/letsencrypt/live/domain.tld/chain.pem
    fullchain = /etc/letsencrypt/live/domain.tld/fullchain.pem
    
    # Options used in the renewal process
    [renewalparams]
    account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    server = https://acme-v02.api.letsencrypt.org/directory
    authenticator = dns-cloudflare
    installer = None
    dns_cloudflare_credentials = /etc/letsencrypt/domain.tld.ini
    
    I think renewing via certbot renew should cover renewing this as well after the lapse of 60 days and before 90 days but I cannot confirm its renewal will work since mine is not subject to any renewal yet. So, please be attentive to friendly-reminding-email from Let's Encrypt just in case its renewal somehow failed after 60 days as you may need to do it manually.
     
    Last edited: May 19, 2018
  2. ahrasis

    ahrasis Active Member

    I was just doing further readings at readthedocs.io and I think the proper way shouldn't be by editing the cli.ini file but firstly, create a (hidden) folder and file for the required credentials.
    Code:
    mkdir /etc/letsencrypt/.secrets
    chown root:root /etc/letsencrypt/.secrets
    chmod 600 /etc/letsencrypt/.secrets
    # Create the credential file
    nano /etc/letsencrypt/.secrets/domain.tld.ini
    
    Then add the required credential inside the file.
    Code:
    # CloudFlare API key information
    dns_cloudflare_api_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    dns_cloudflare_email = [email protected]
    
    And lastly, run certbot using the right plugin for the wanted domain(s) via dns.
    Code:
    certbot certonly \
      --dns-cloudflare \
      --dns-cloudflare-credentials ~/etc/letsencrypt/.secrets/domain.tld.ini \
      --server https://acme-v02.api.letsencrypt.org/directory \
      --agree-tos \
      --dns-cloudflare-propagation-seconds 60 \
      -d domain.tld \
      -d *.domain.tld
    

    In the addition to the above, since I think many ISPConfig servers use Bind, (I may be wrong) we may use certbot dns_rfc2136 plugin in almost similar way as above (except that creating their credentials are a bit unique and I haven't test my readings about it in full).

    The idea is firstly to install the plugin via "apt install python3-certbot-dns-rfc2136", and then create the credentials using "dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST domain.tld." for keyname, secret and algorithm (which, I think, we may use the default or the modified default function in ISPConfig DNS Server to create them) where two files will be created key and private; for examples Kdomain.tld.+165+28266.key and Kdomain.tld.+165+28266.private.

    Finally, use its credentials to fill up domain.tld.ini file and run certbot like in the sample codes below.
    Code:
    # Target DNS server
    dns_rfc2136_server = 192.168.0.101
    # Target DNS port
    dns_rfc2136_port = 53
    # TSIG key name
    dns_rfc2136_name = domain.tld.
    # TSIG key secret
    dns_rfc2136_secret = UQOjbPh0ttDY7gzojmSSCurRGIOCM0fdCuPZJZc8Ma4uQFEGDe+sOrQ/ rlmEUQ8Jdozwkd/Vw6oKfDkAx/H+/g==
    # TSIG key algorithm
    dns_rfc2136_algorithm = HMAC-SHA512
    Code:
    certbot certonly \
      --dns-rfc2136 \
      --dns-rfc2136-credentials ~/etc/letsencrypt/.secrets/domain.tld.ini \
      --server https://acme-v02.api.letsencrypt.org/directory \
      --agree-tos \
      --dns-rfc2136-propagation-seconds 60 \
      -d domain.tld \
      -d *.domain.tld
    

    It will be nice if I can write at least this up in a proper ISPConfig way, so that it can be contributed to the git but my knowledge is quite limited. :( Hopefully in ISPConfig version 3.2 we will see an option to obtain Let's Encrypt SSL certs via dns to certain extends.

    Edited: The above code for both ISPConfig and CloudFlare is now ready to be rewritten in ISPConfig. ;)
     
    Last edited: Aug 6, 2018
    ztk.me likes this.
  3. ahrasis

    ahrasis Active Member

    An automatic update to certbot version 25 recently and subsequently a request for another certificates shows that the plugins need to be re-installed after any version update as they may not be configured to be used with the new version.

    Running "apt -y install python3-certbot-dns-rfc2136 python3-certbot-dns-cloudflare python3-cloudflare --reinstall" before any new request is made after the update, should do it.

    Hopefully I find some times to do a proper plugins / modifications for ISPConfig next time. :D
     
    Taleman likes this.
  4. ahrasis

    ahrasis Active Member

    Now I can confirm that the renewal of my domain and its wildcard via cloudflare dns is working.

    For those who are using the same method but got error in renewal for the domain and its wildcard, they should check the CAA entry which basically should consist of two CAA as follows:
    Code:
    CAA    domain.tld    0    issue "letsencrypt.org"    automatic
    CAA    domain.tld    0    issuewild"letsencrypt.org"    automatic
    The first is for the domain and the second is for its wildcard. That means if you want to create certs for sub.domain.tld only, you will need to create a CAA entry just for it. You can check you CAA entry via command "dig caa domain.tld" or via online service like at https://dnsspy.io/labs/caa-validator.

    I think I can now try to write the this modification for letsencrypt in ISPConfig related files.
     
    till likes this.
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    Please consider setting permissions of the .secrets directory explicitly to a secure value. E.g.:

    Code:
    chown root:root /etc/letsencrypt/.secrets
    chmod 600 /etc/letsencrypt/.secrets
     
    ahrasis likes this.
  6. ahrasis

    ahrasis Active Member

    I just updated post #2 above with @till suggestions and with some extra, and I think they are now ready to be re-written for ISPConfig. Hopefully I am free to write them soon.
     

Share This Page