Let's encrypt coming soon

[SmallGuy]

FYI
https://letsencrypt.org/

 

[Craig321]

Just got my beta invite to this. Would LOVE to see integrated support via the FreeNAS GUI if that's possible!

 

[DrKK]

Just got my beta invite to this. Would LOVE to see integrated support via the FreeNAS GUI if that's possible!

Integrated support in the FreeNAS GUI for *what* exactly?

This is a Certificate Authority. What would you have FreeNAS do? You can already put in whatever Certificate Authority you want.

 

[Craig321]

For the generation and automatic renewal of Let's Encrypt free certificates.

So just a simple interface where you can put your Let's Encrypt details and FreeNAS will run the necessary commands for you.

To generate a Let's Encrypt certificate, there are some commands you have to run which relies on a few dependencies which aren't there by default in FreeNAS.

 

[DrKK]

I see.

I quickly perused the site, and I must not understand something yet. All I see is a solution to a problem no one really has. I will assume I just don't get it yet, and that I will become less stupid with time and see the light.

 

[Ericloewe]

I see.

I quickly perused the site, and I must not understand something yet. All I see is a solution to a problem no one really has. I will assume I just don't get it yet, and that I will become less stupid with time and see the light.

The point is to provide easy access to certificates (for HTTPS, mostly), since getting a certificate from a CA is not the most trivial thing in the world. Haven't really read up on the details, though.

 

[Craig321]

It's more the free-ness over the easy access. There is only one free certificate provider, StartSSL, who I have had my cert from for the last few years, but it always seems to be a right hassle to get it done with them.

Also, for the less savy users, it might be a struggle to find the right key and the certificate and paste them in to FreeNAS as some cert providers don't give you the certificate in an 'easy to use' format.

It's just something I'd love to see and don't see a reason why not (time permitting of course) considering it's going to be totally free!

I was able to generate a Let's Encrypt cert on an Ubuntu server, then transfer it across to my FreeNAS box, but that's a bit of a pain as it requires changing of the A record to the server you're generating on, then changing back when done! I did give it a quick try on FreeNAS itself, and I'm sure I could get it working, but it was missing a bunch of dependencies.

P.S - I wouldn't be that bothered if they provided 1 year certs as I'd just fire up Ubuntu every year, renew and be done with it. However, the idea behind Let's Encrypt is that you renew, using an automatic process (some sort of script I guess) every 90 days (I think it's every 30 or 60 while in beta). Don't know why, but that's the way they're going to do it apparently, so again something in FreeNAS that would auto-renew would be amazing. I guess this might get more traction when it's actually released & more people are using.

 

[SmallGuy]

https://github.com/letsencrypt/letsencrypt/issues/293
Think this isn't for tomorrow.
Some works has to be done on FreeBSD first (Some trials can be done under jail).
I'm interest too, but busy at the time to investigate.

 

[Craig321]

Cool, thanks for the link :)

 

[AliceWonderMiscreations]

I was excited about this before the details were released, now not so much.

I am not in favor of automated scripts that listen on port 443, interact with a remote server, and then have write permission to the server config file - running fairly frequently at a predictable schedule.

Sooner or later a Let's Encrypt automated client is going to get p0wn3d.

I wish they simply offered 1 year certs where you can validate you own the domain via e-mail. I'll be sticking with Comodo.

Oh. and Comodo also offers ECDSA certs, which I like even though some clients (older Android is still common on brand new prepaid phones) do not support it yet. Let's Encrypt for some reason only does RSA certs.

 

[Ericloewe]

I was excited about this before the details were released, now not so much.

I am not in favor of automated scripts that listen on port 443, interact with a remote server, and then have write permission to the server config file - running fairly frequently at a predictable schedule.

Sooner or later a Let's Encrypt automated client is going to get p0wn3d.

I wish they simply offered 1 year certs where you can validate you own the domain via e-mail. I'll be sticking with Comodo.

Oh. and Comodo also offers ECDSA certs, which I like even though some clients (older Android is still common on brand new prepaid phones) do not support it yet. Let's Encrypt for some reason only does RSA certs.

The million dollar question right now is why the NSA suddenly started advising against elliptic curve cryptography.

I feel the sane course of action is to continue adopting elliptic curve cryptography normally, while looking for signs that it's been broken - it's hard to shake the feeling they might actually be acting in the public's interest for once...

 

[AliceWonderMiscreations]

There are currently only two curves widely accepted by browsers and both of those curves, we don't know the process behind how the parameters were chosen. That may be what the NSA is worried about, and I'm worried about it too though my worry is the NSA was behind the parameter selection.

Hopefully that will be remedied soon and browsers will support some of the curves with transparency.

The NSA gave use SELinux so they have acted in our benefit before.

 

[jgreco]

The point is to provide easy access to certificates (for HTTPS, mostly), since getting a certificate from a CA is not the most trivial thing in the world. Haven't really read up on the details, though.

That's the thing. When they've finally taken a grinder to all the awful edges on this thing, the potential is there to just throw a cron job on your web server to keep the certificate valid ... basically forever.

I just finished butchering this to work on FreeBSD and I have to say that I'm actually really frickin' impressed. It is reminiscent of the early days of SSL where it was all kinda arcane, but I can see the POTENTIAL this thing has. Fundamentally, SSL has been hamstrung by all the CA bullcrap. Some companies (mine included) just set up their own CA and install a root cert into everything in order to be able to issue certs with impunity. I like issuing them for ten years because otherwise it gets to be a chore to wander around renewing certificates on this-and-then-that-and-then-the-other-thing every week. Downside is that this only works for internal sites, external stuff is still a problem. This solves that.

I am not in favor of automated scripts that listen on port 443, interact with a remote server, and then have write permission to the server config file - running fairly frequently at a predictable schedule.

Sooner or later a Let's Encrypt automated client is going to get p0wn3d.

You can do it nearly completely manually, just giving the client write access to a well known directory on :80 instead (should be able to do this as nobody, haven't quite gotten to that point yet). No need to write to the server config file, dunno where you get that idea, you can just have it poop out its key/certs and then refer to those files from the server config file. You're looking for "certonly --webroot".

Bearing in mind that anything installed here is not done through defaults or prebuilt packages, and always involves putting things in nonstandard directories, it nevertheless only took me about two hours of f***ing around to get all the way from "there's the download page" to "Qualys SSL Test gives this an A" including working my way through some early adopter bugs such as the e-mail A/MX issue. My resulting work isn't actually fully automated yet and there's a whole bunch of testing I'd need to do before releasing it for testing, but this ... guys, this is one of the tools we really need to take SSL to the next level on the Internet. I suggest you embrace it.

I'm happy to discuss this at more length as someone who's been anxiously watching the developments here for awhile.

 

[xaibex]

I just tried letsencrypt with "certonly --webroot" on my nginx server and i really like how easy it is. Even easier than getting a certificate from startSSL. Plus it supports sub-domains! Perfect for Home and/or small Office use!
An little GUI Wizard within freenas would be so freaking awesome!
So long I just run a jail with letsencrypt and a nginx reverse proxy pointing to my freenas GUI and other Services on the Box.

 

[jgreco]

Yeah, it's got some serious rough edges, not the least of which is that it is written in a scripting language that also requires some prereqs to be installed, and which will happily try to spam your base system in order to accomplish that. Also, they've got some problems on the server side, most notably that a mail domain that only has an MX record (we call that "properly designed") is rejected by their server. I also don't care for the fact that it attempts to do update and install operations when you run it, though I can see how getting a project like this bootstrapped has to be a real PITA. The biggest improvement they could make, IMO, would be to allow their validation thingy to run on an alternate port instead of :80 or :443.

 

[xaibex]

Its software is obviously not in a mature state. But every software have it's discrepancies.

I totaly agree with your point to allow other ports than 80/443. But i found that it's not that bad because you can just use a running Web-Server with "certonly --webroot"

If your sub.domain.tdl points to /var/www you just have to run letsencrypt with "letsencrypt-auto certonly --webroot -w /var/www/ -d sub.domain.tdl.

Your running Server will remain running. And you will get your cerfiticates. Only thing that happens is that letsencrypt temporary copies some files for its certificate request into your webroot. (ok this need (temp) file access too)

 

[jgreco]

I totaly agree with your point to allow other ports than 80/443. But i found that it's not that bad because you can just use a running Web-Server with "certonly --webroot"

<cynical voice> So you're repeating the suggestion I gave above, back to me.

If your sub.domain.tdl points to /var/www you just have to run letsencrypt with "letsencrypt-auto certonly --webroot -w /var/www/ -d sub.domain.tdl.

Your running Server will remain running. And you will get your cerfiticates. Only thing that happens is that letsencrypt temporary copies some files for its certificate request into your webroot. (ok this need (temp) file access too)

Perhaps you could enlighten us all where the webroot directory should be pointed if you're serving content with Node, or a load balancing proxy, or serving files from a read only filesystem.

 

[xaibex]

I am really sorry to agree with you. Will never do it again. Your statement schould be the only one.

When you run Reverseproxy or anything else, you can create a nginx rule to allow ACMA requests from all virtual hosts (See here)

/Edit: Read-only-filesystem is still a problem. Maybe some experienced freenas/freebsd developer might have a solution to this?

 

[jgreco]

It seems like a more prudent fix would be, instead of hatcheting things to work around the deficiency, to instead address the deficiency. The letsencrypt thing is just code, after all, on both sides.