Remotely add/install TLS certificates on FreeNAS server?

[danb35]

I'm excited about the LetsEncrypt service--free, trusted SSL certificates, with support for multiple domains/hostnames and automated renewal is, IMO, a big deal. I have one of their certificates on my main web server, another on my FreeNAS box, and a third on another internal Linux server. I also have a script running via a cron job on my web server to renew the certificates every other month, and renew them all on the web server, since it's the only machine directly exposed to the 'net.

Installing/activating the cert on the web server is simplicity itself--since the certs are symlinked to /etc/letsencrypt/live/domain/cert.pem (and related files), nothing changes in the config at all--just need to reload apache to load the new cert.

Installing/activating the new cert on the other Linux server is pretty simple too--simply scp the appropriate files to the appropriate locations on that server, then 'ssh root@host service httpd reload'. No problem to script that.

Where I'm lost is in getting the cert files to my FreeNAS box. Sure, I can just view the files and copy/paste them into the web GUI, but where's the fun in that? I could easily scp them to the FreeNAS box, but that doesn't get them into the config database. Is there a straightforward way to upload/install those files via a script?

 

[depasseg]

There is a freenas API. Maybe that could work?

 

[danb35]

Interesting. Looking at the docs, it's a little over my head (but what else is new?). The manual has some samples, and it appears that the relevant parameters are documented at http://api.freenas.org/resources/system.html#ssl, but there's nothing there showing that you can upload a certificate that way. Looks like it's time for some tinkering.

 

[jgreco]

The big problem here is that the letsencrypt stuff will likely be ratcheting down the validity property from its current several months. So you really need some sort of mechanism to keep it up to date.

Having them in the config DB is therefore not super meaningful.

Perhaps a script to copy them over from your other gear on a daily basis (and at boot)? That also gives you a hook to do the reload of the web server.

 

[danb35]

Well, the current validity is 90 days, and the recommendation seems to be to renew every 60 days or so. I have a renewal script on a cron job to run every other month, but of course it's easy enough to change the schedule as appropriate. A better mechanism would, of course, be to run the script much more frequently (e.g., daily), have it check the validity of the existing cert, and execute the renewal when there are less than n days of validity remaining on the cert--but that takes a bit more finesse with the script, and I'm more on the BFI end of the scale. OTOH, it wouldn't require me to keep up-to-date with how long their certs are valid.

Having them in the config DB is therefore not super meaningful.

I'm afraid I don't understand this. When a new cert is issued, placing it into the config DB seems like the right thing to do. It's then up to the middleware to write out the correct files, restart the relevant services, etc. I'm not sure that there's a good way to automate putting it into the config DB, but it seems to me that this should be the goal.

Perhaps a script to copy them over from your other gear on a daily basis (and at boot)?

Interesting, I hadn't thought of this. So the script would run on the FreeNAS server, scp files from the other server, and restart nginx? It would mean that the config db wouldn't reflect the actual state of the server, which seems undesirable, but not necessarily fatal. OTOH, it wouldn't require me to learn how to interact with the API, which is a plus, as I'd be starting from zero on that.

 

[jgreco]

crap, stupid webui didnt mark this for followup. i have commentary but am on the far side of a crap IP cxn. ping this thread if no followup in the next day or so.

 

[jgreco]

Well, the current validity is 90 days, and the recommendation seems to be to renew every 60 days or so. I have a renewal script on a cron job to run every other month, but of course it's easy enough to change the schedule as appropriate.

Expect that to break sooner or later. The tone of the discussion seems to be to move towards shorter certs once the mechanism for updating is solid.

A better mechanism would, of course, be to run the script much more frequently (e.g., daily), have it check the validity of the existing cert, and execute the renewal when there are less than n days of validity remaining on the cert--but that takes a bit more finesse with the script, and I'm more on the BFI end of the scale. OTOH, it wouldn't require me to keep up-to-date with how long their certs are valid.

That part of it is pretty trivial. You can use OpenSSL to check the validity remaining on a certificate. A sample code snippet:

Code:

if [ -d /www/letsencrypt ]; then
        cert=`ls /www/letsencrypt/etc/live/*/cert.pem | head -1`

        if [ -f "${cert}" ]; then
                if openssl x509 -checkend 604800 -noout -in "${cert}"; then
                        # Certificate good for at least 7 days
                else
                        /www/letsencrypt/letsencrypt-runner && (echo "letsencrypt certificate renewed" | Mail -s "httpd service status" ${notify})
                        killall -HUP httpd || (echo "killall -HUP httpd failed" | Mail -s "httpd service problem" ${notify})
                fi

                if openssl x509 -checkend 345600 -noout -in "${cert}"; then
                        # Certificate good for at least 4 days
                else
                        echo "letsencrypt certificate renewal is failing" | Mail -s "httpd service problem" ${notify}
                fi
        else
                echo "No certificate identified for letsencrypt" | Mail -s "httpd service problem" ${notify}
        fi
fi

You run that sort of thing on a generic FreeBSD or Linux webserver once daily, and it'll keep your cert up to date.

I'm afraid I don't understand this. When a new cert is issued, placing it into the config DB seems like the right thing to do. It's then up to the middleware to write out the correct files, restart the relevant services, etc. I'm not sure that there's a good way to automate putting it into the config DB, but it seems to me that this should be the goal.

I expect that's a misunderstanding of how things work. You placing something in the config DB isn't going to tease the middleware into doing anything with it. What you would want, to make this work, is an API to update the certificate. The API is a gateway into the middleware, which would then store it in the database, and would also make the middleware aware that something had happened, which is then cause for further action, such as creating certificate files and updating httpd.

Absent an API or some other more specialized mechanism for the middleware to detect that something has unexpectedly changed underneath it in the DB, there's no reason to think that the middleware would act on your changed certificate.

Now, ideally, yeah, API = way to go. That would mean you're never fighting the system. But the ghetto way to do it is just to bap the stuff into place and HUP the httpd yourself. You'd want a hook to do this on bootup and then probably daily or something like that.

Interesting, I hadn't thought of this. So the script would run on the FreeNAS server, scp files from the other server, and restart nginx? It would mean that the config db wouldn't reflect the actual state of the server, which seems undesirable, but not necessarily fatal. OTOH, it wouldn't require me to learn how to interact with the API, which is a plus, as I'd be starting from zero on that.

API's aren't terrible, but if they don't have the thing you need, then you have to hatchet around it. I don't know since I haven't looked.

The real thing here is that it'd be great to have FreeNAS support LE directly, but that implies that the FreeNAS would need to be visible to the Internet, which is, of course, bad. Sigh.

 

[danb35]

I expect that's a misunderstanding of how things work. You placing something in the config DB isn't going to tease the middleware into doing anything with it

I think my misunderstanding was that I was conflating actually making the DB entry with taking the appropriate "sanctioned" steps to do so--either through the web GUI or through the API. I think the point you're making is that if I just start banging around with sqlite on freenas-v1.db, I shouldn't expect a good outcome. Makes sense.

The real thing here is that it'd be great to have FreeNAS support LE directly, but that implies that the FreeNAS would need to be visible to the Internet, which is, of course, bad.

...and there's the legitimate question of why development time should be spent doing that, when the server should only be used on a protected LAN. OTOH, if that's the argument, why support HTTPS for the web GUI at all? But yes, it'd be difficult to run the LE client on FreeNAS, while keeping the system protected as it should be, and especially difficult to automate it. I could probably make it work, since I have my own public-facing web server--come up with a way to mount the web root on the FreeNAS box, and tell the client to write the challenge file there. But I expect a small minority of FreeNAS users are in this situation.

The tone of the discussion seems to be to move towards shorter certs once the mechanism for updating is solid.

They've already got a lot of people hacked off over the 90-day lifetime, mainly, I think, because manual issuance is a bit of a hassle. Shortening it even further isn't going to help. Unless they're going to openly take the position that they're only interested in providing certs to customers who are able and willing to use client software for automatic issuance and renewal, and that anyone else should really look at using a different CA.

 

[jgreco]

OTOH, if that's the argument, why support HTTPS for the web GUI at all?

Because having lots of soft squishy unprotected yumminess on your internal networks often gets you pwned. Ask any of the major merchants whose payment card processing systems have been subverted in the last several years. The arrogant arseholes who think they can get away without providing proper security compartmentalization and tiering, or that they don't need to use encryption to protect things, etc.

But yes, it'd be difficult to run the LE client on FreeNAS, while keeping the system protected as it should be, and especially difficult to automate it. I could probably make it work, since I have my own public-facing web server--come up with a way to mount the web root on the FreeNAS box, and tell the client to write the challenge file there. But I expect a small minority of FreeNAS users are in this situation.

They've already got a lot of people hacked off over the 90-day lifetime, mainly, I think, because manual issuance is a bit of a hassle. Shortening it even further isn't going to help. Unless they're going to openly take the position that they're only interested in providing certs to customers who are able and willing to use client software for automatic issuance and renewal, and that anyone else should really look at using a different CA.

The short lifetime and automation was always part of the deal. Maybe people who want something different should set up their own CA and run it the way they wish.