Vesta: LetsEncrypt Integration (September)

[SysVoid]

Plans should be made to integrate LetsEncrypt (https://letsencrypt.org) in September. This removes the need to have self-signed certs.

[nobodypb]

Well didn't hear of that yet.
+1

[Lexiv]

+1

Hope that will be implemented soon!

[ashwin31]

+1

[oleglopeta]

+1

[tabuna]

+1

[oasisfleeting]

+1

[superservidor]

+1

[superservidor]

+1

[SysVoid]

Update

LetsEncrypt is not due for full release until November, but support can still be added in the Sept—Nov date range.

[oasisfleeting]

https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html

[SysVoid]

Thanks @oasisfleeting!
It's still not fully released (still BETA/ALPHA afaik), but the integration would be useful by someone if they have time.

@serghey-rodin ping

[marcelloinfoweb]

+1

[Lednerb]

+1

[r3sist]

+1

[hellodanielting]

Does this entail using Let's Encrypt in place of self-signed certs when adding a new "Website" ?
I think that Let's Encrypt should also be used during the installation process to produce a valid cert for the CP login. However, given the ACME protocol, this might want take awhile.

[pabloko]

Well, letsencrypt started issuing certs days ago.

At the moment my toughts using it, so far, so good. But working with vesta... made this a little of messy.

Problem comes at issuing/reissuing a certificate (letsencrypt is issuing short lived certificates, with 90 days expiry, so you have to automate the task of reissuing certificates) vesta actually need a certificate input in order to create/save a domain config, but letsencrypt needs to verify domain ownership by placing an http call to domain/subdomains that will be issued.

To solve this, i just created an nginx config, lets call "/etc/nginx/letsencrypt.conf"

location ^~ /.well-known/acme-challenge/ {
        default_type    "text/plain";
        root            /var/www/letsencrypt;
    }

    location = /.well-known/acme-challenge/ {
        return          404;
    }

and added "include /etc/nginx/letsencrypt.conf;" on all nginx templates, this will eneable letsencript's webroot plugin to use same directory on all sites to verify.

fe: $ letsencrypt certonly --webroot -w /var/www/letsencrypt/ -d domain.tld -d www.domain.tld -d sub.domain.tld

you should issue the domain and aliases, but vesta add as alias sometimes domains that are not pointed througt dns, if some domain fail, all issuing will fail. it also add a generic master server subdomain, that will cause reissue of master domain cert with only this subdomain overriding the others...

And properly editing vesta to add letsencrypt support will be messy because current integration do certificate stuff before config is set so will need some amount of work to be properly done.

I will try to do it and do a pull request

[Lednerb]

It seems to me that this might be a good idea.

Maybe my workaround can help you further:

Firtst I've created the certs via the --webroot method.

Than i configured my domains to use ssl (nginx with force-https) and for this i clicked through the vesta create certificate process, copied cert and key and saved the domain.

After that step i cd in the config folder via ssh and overwrote the ssl files via symlinks as the following:

1. ln -fs /etc/letsencrypt/live/domain.privkey ssl.domain.key
2. ln -fs /etc/letsencrypt/live/domain.fullchain.pem ssl.domain.crt
3. ln -fs /etc/letsencrypt/live/domain.fullchain.pem ssl.domain.pem

With this workaround i can run letsencrypt again with the same params and vesta does not fail.

I'm sure that's not the best way to do this but until now it works.

[pabloko]

hi @Lednerb yep, symbolic linking certificates is the recommended by letsencrypt in order to maintain sanity on the system, the point of this is on automating all this task.

What you see here is the valid san table that letsencrypt will be able to issue and validate trought acme and webservice http connection

Im currently editing ssl system and some scripts to enable letsencrypt automaticly that can check SAN table, creating crontabs to renew certs etc.

At this time, seems i only will be able to use letsencrypt at edit time only, not when creating a domain, also managing subdomains created as domain will be a little messed up...

[tarikin]

+1

[pabloko]

Ok guys, my first integration is now working. Its ugly, bad coded and messy, but works and do what i need.

First of all we need to setup the nginx configuration and insert an include on all proxy templates, then rebuild.

The process is quite easy, just create and configure some domain and edit it (its only allowed to create certificates when domain is created and can be accesed) you will have this section:

Now just click on "Issue now" page will load again and you will see a message with success or failing log

Then you will see something like this

Now just check SSL Support and your certificates will be there

This is still wip, need to automate renewal and fix reissuing bugs and building time bugs, but from now its usable.

---

[Changes]

Install from git letsencrypt, do a first run with --help argument...

Create dir /var/www/letsencrypt
Create dir /var/www/letsencrypt/.well-known
Create dir /var/www/letsencrypt/.well-known/acme-challenge
Create file /var/www/letsencrypt/.well-known/acme-challenge/status

This file will be used to check if domain is well configured agains letsencrypt verification, you can also chown this files and folder to www-data in case you use hosting template

Cretate: /etc/nginx/services.conf

include             /etc/nginx/services/letsencrypt.conf;

Create folder /etc/nginx/services
Create file /etc/nginx/services/letsencrypt.conf

    location ^~ /.well-known/acme-challenge/ {
        default_type    "text/plain";
        root            /var/www/letsencrypt;
    }

    location = /.well-known/acme-challenge/ {
        return          404;
    }

Add to all you proxy tpl and stpl at ending

include             /etc/nginx/services.conf;

rebuild?
Create the script /usr/local/vesta/bin/v-letsencrypt-issue

#!/bin/bash
# info: issue letsencrypt certificate
# options: USER DOMAIN [DOMAINS_CHAIN]
#


#----------------------------------------------------------#
#                    Variable&Function                     #
#----------------------------------------------------------#

# Argument defenition
user=$1
domain=$2
domains=$3

# Includes
source $VESTA/func/main.sh


#----------------------------------------------------------#
#                    Verifications                         #
#----------------------------------------------------------#

check_args '2' "$#" 'USER DOMAIN [DOMAINS_CHAIN]'
is_object_valid 'user' 'USER' "$user"
is_object_valid 'web' 'DOMAIN' "$domain"

#----------------------------------------------------------#
#                       Action                             #
#----------------------------------------------------------#

if [[ $domains = *[!\ ]* ]]; then
    echo -e "/root/.local/share/letsencrypt/bin/letsencrypt certonly --renew-by-default --webroot -w /var/www/letsencrypt/ $domains" > $USER_DATA/ssl/$domain.letsencrypt
    chmod 0770 $USER_DATA/ssl/$domain.letsencrypt
fi

issuer = $( exec "$USER_DATA/ssl/$domain.letsencrypt" )

if [ -e "/etc/letsencrypt/live/$domain/cert.pem" ]; then
    cp -f "/etc/letsencrypt/live/$domain/cert.pem" "$USER_DATA/ssl/$domain.crt"
    cp -f "/etc/letsencrypt/live/$domain/chain.pem" "$USER_DATA/ssl/$domain.ca"
    cp -f "/etc/letsencrypt/live/$domain/fullchain.pem" "$USER_DATA/ssl/$domain.pem"
    cp -f "/etc/letsencrypt/live/$domain/privkey.pem" "$USER_DATA/ssl/$domain.key"
    echo -e "LetsEncrypt SSL Verification done :D"
else
    echo -e "LetsEncrypt SSL Verification could not be made: $issuer"
fi


#----------------------------------------------------------#
#                       Vesta                              #
#----------------------------------------------------------#

exit

Create script /usr/local/vesta/bin/v-letsencrypt-check

#!/bin/bash
# info: check letsencrypt certificate
# options: USER DOMAIN
#


#----------------------------------------------------------#
#                    Variable&Function                     #
#----------------------------------------------------------#

# Argument defenition
user=$1
domain=$2

# Includes
source $VESTA/func/main.sh


#----------------------------------------------------------#
#                    Verifications                         #
#----------------------------------------------------------#

check_args '2' "$#" 'USER DOMAIN'
is_object_valid 'user' 'USER' "$user"
is_object_valid 'web' 'DOMAIN' "$domain"

#----------------------------------------------------------#
#                       Action                             #
#----------------------------------------------------------#
if [ -e "$USER_DATA/ssl/$domain.crt" ]; then
    echo -e "$USER_DATA/ssl/$domain.crt"
    ltse=$(openssl x509 -text -noout -in "$USER_DATA"/ssl/"$domain.crt" | grep DNS:)
    echo -e $ltse
    ltsed=$(openssl x509 -enddate -noout -in "$USER_DATA"/ssl/"$domain.crt")
    echo -e $ltsed
fi

#----------------------------------------------------------#
#                       Vesta                              #
#----------------------------------------------------------#

exit

(for this code i can only say sorry guys, never worked on shell scripts)

Add this code to /usr/local/vesta/web/templates/admin/edit_web.html (just before web statics)

<tr>
                                <td class="vst-text step-top">
                                    <label>LetsEncrypt SSL</label><br />
                                    <div style="background-color:#e0e0e0; font-weight:normal; padding:10px;margin-top:5px;"><?php echo $v_san_table ?><br/>
                                       <small>Certificate status: <?php echo $v_letsencrypt_status ?><br /></small><br/>
                                       <input type="hidden" name="v_letsencrypt_domains" value="<?php echo $v_san_command ?>" />
                                       <input type="hidden" name="v_letsencrypt_issue" id="v_letsencrypt_issue" value="0" />
                                       <input type="button" class="button" onclick="document.getElementById('v_letsencrypt_issue').value='1'; this.form.submit();" name="letsencryptissue" value="Issue now">
                                    </div>
                                </td>
                            </tr>

you can also add this to templates/user to make issuing available to regular users

Insert this code on /usr/local/vesta/web/edit/web/index.php

...
// Check token
    if ((!isset($_POST['token'])) || ($_SESSION['token'] != $_POST['token'])) {
        header('location: /login/');
        exit();
    }

    //Pabloko: LetsEncrypt issue cert
if ($_POST['v_letsencrypt_issue']=="1")
{
    exec (VESTA_CMD."v-letsencrypt-issue ".$user." '".$v_domain."' '".$_POST['v_letsencrypt_domains']."'", $issue_out, $return_var_ssl);
    $_SESSION['error_msg'] = $issue_out[0];
}

and also

//Pabloko: Build SAN table
$v_san_table="";
$v_san_command="";

function check_acme_challenge($domain) {
    if (trim(file_get_contents("http://".$domain."/.well-known/acme-challenge/status"))=="OK") 
    {
        return true;
    }
    return false;
}

if (check_acme_challenge($v_domain)) {
    $v_san_table .= $v_domain."<br/>";
        $v_san_command .= "-d ".$v_domain." ";
}

foreach($valiases as $v_alias ) {
    if (check_acme_challenge($v_alias) && strpos($v_alias, $v_domain) !== false) {
              $v_san_table .= $v_alias."<br/>";
              $v_san_command .= "-d ".$v_alias." ";
    }
}

$v_letsencrypt_status = "<span style='color:red;'>Certificate not issued</span>";

if (!empty($v_ssl_crt)) {
    $v_letsencrypt_status = "<span style='color:green;'>Issued to (";
    exec (VESTA_CMD."v-letsencrypt-check ".$user." '".$v_domain."'", $ossl_out, $return_var_ssl);
    $v_letsencrypt_status .= str_replace("DNS:","",$ossl_out[1]).")</span><br />Expires in: <span style='color:green;'>".str_replace("notAfter=","",$ossl_out[2])."</span>";
}

// Header
include($_SERVER['DOCUMENT_ROOT'].'/templates/header.html');
...

The issuing process will generate a script file on /usr/local/vesta/user/username/ssl/domain.tld.letsencrypt that contains a copy of letsencrypt issue command, so you can use:

v-letsencrypt-issue user domain.tld -> will use last configuration and reissue certificate
v-letsencrypt-issue user domain.tld '-d domain.tld -d alias.domain.tld...' -> will write configuration an issue certificates

UPDATE:

just forgot to mention an update on /usr/local/vesta/web/edit/web/index.php

// Pabloko: skip ssl lookup and obtain certificates anyway
//if ( $v_ssl == 'yes' ) {
    exec (VESTA_CMD."v-list-web-domain-ssl ".$user." '".$v_domain."' json", $output, $return_var);
    $ssl_str = json_decode(implode('', $output), true);
    unset($output);
    $v_ssl_crt = $ssl_str[$v_domain]['CRT'];
    $v_ssl_key = $ssl_str[$v_domain]['KEY'];
    $v_ssl_ca = $ssl_str[$v_domain]['CA'];
//}

Commenting out this is needed in order to read the cert even if ssl isnt on

---

sorry for long post, hope someone has more time than me and could help with this.

[hellodanielting]

Thank you for the efforts @pabloko . Your write-up is much appreciated.

[cricsus]

well, you can basically use startCom SSL ( https://startssl.com ) for top-level Domains as well. And thats also for free and accepted by most browsers.

Wether you use a certificate issued by StartCom or let's-encrypt, there shouldn't be any difference for you (except you use a web-GUI when using StartCom and won't have to put commands in the SSH all the time..)

So adding it won't be bad maybe (except the usage of ressources and also the fact that there is still no stable release of let's-encrypt yet), but I actually do not see it as a neccessarity in any way...

PS: I think it's still the best method to create your own CA, use your own Intermediate CA to sign your certificate and use Cloudflare (Option "Full SSL" under the menu "Crypto") since it will show a certificate issued by Comodo CA Ltd., while still connecting to your server with your own certificate issued by your own CA. So the Client will still get the green bar ^^

[KeiroD]

@cricsus: I would not suggest your described method at all. If a client decides to move away from Vesta, they'll find out very quick that your SSL certificate is in fact, NOT trusted.

[KeiroD]

@pabloko I would add what you've done in a pull request.

[cricsus]

@KeiroD: using own CA requires you to use CloudFlare's DNS and so on. Meaning a client would have to point to Cloudflare ("CF") and from there, he would have to manage his domain's DNS records thru CF and point A-records etc. to ur server.

It's of-course BS-method to recquire ur clients to point to CF first and then to ur server if ur a hosting-provider. But well, you don't have to give SSL certificates to your clients as a hosting-provider anyways, do you? They can easily acquire it by buying one, or by requesting it for free over startCom or doing that let's-encrypt stuff themselves at their own risk.

So: own CA + CloudFlare seems actually to be an almost excellent solution if ur hosting ur own domains on ur server. At least that's how I think of it. (Ofc. requires the client browsers to support SNI tho. So might not work for XP or IE6 users etc.)

[cricsus]

Byw. There is a suggestion on this for Vesta adding let's-encrypt.
Link: https://bugs.vestacp.com/responses/site-encryption-with-letsencrypt

[pabloko]

@KeyroD i think its still missing important stuff needed for a pull request, certificates are copied instead linking, theres no monthly renewal crontab yet, and its still needed some fix on code after edit the domain, also will be better to group certificates for domain allowing all subdomains instead creating it for single web configs. also verification process needs fixes to correctly check against dns the verification process.

I see pointless using cloudflare and also mention that startssl free certs are only available for personal and non comercial sites. Only way to just have ssl working now its using letsencrypt or buying a certificate that fullfill your needs

[KeiroD]

@pabloko Maybe do a PR anyway and let others help test it? Or do you have a github repository to test LE integration that we can help test with before you do a PR for here?

[SysVoid]

@cricsus though what you are saying about CloudFlare makes sense, it just makes MORE sense to use something that is supported, is free, and requires no third-party DNS management.

@pabloko if you have working source for it, upload it so we can help you finalise it. :)

[pabloko]

@SysVoid just take a look 10 posts above https://github.com/serghey-rodin/vesta/issues/425#issuecomment-162875068

[pabloko]

btw, forked vesta to work on letsencrypt branch, PR's allowed ;)
https://github.com/pabloko/vesta

All changes will be commited today. Regards

Edit:

Commited my changes
https://github.com/pabloko/vesta/commit/27e855223cc024e2d3fee03c69ceedffed1cd9fe

[serghey-rodin]

How come this issue went unnoticed by us :) This is awesome. We are going to add LetsEncrypt support into main branch.
@pabloko Would you mind if I will use your work to speedup integration process?

[pabloko]

Hi @serghey-rodin yeah i've posted this pretending to become official, unfortunelly i dont have a lot of free time to do this properly and just time to make it work for me.

Feel free to take a look to the repo https://github.com/pabloko/vesta/commit/27e855223cc024e2d3fee03c69ceedffed1cd9fe and use what u need, i can also do enhancements with time if you need them. Theres a bug list on the commit and also renewal process is still very early.

[serghey-rodin]

Thanks!

[gionniboy]

+1 for this feature ... and an advice:
maybe a cronjob every 90days to update let's encrypt certificate automatically?
it will be very useful imho.

more info about that:

https://letsencrypt.org/2015/11/09/why-90-days.html

[nobodypb]

Cronjob is absolutly necessary. If you don't build in automatic renewing this feature would be kinda useless because the user would need to set up Let's Encrypt anyway.
I'd recommend simp_le instead of the standard Let's Encrypt client, because it's lightweight and simple, but able to do everything we need. I'm using it successfully in production environments.
Also cronjob has to run more frequently than every 90days if you don't want expired certificates.
Let's Encrypt renews after 60 days but it is also safe to request everyday.

[skurudo]

LE integration added, closed.