Let's Encypt support

yodaphone

@singerie:

Package is there in the nightly, but i don't know how to use it … lol

It depends on what you want to do with it. For the GUI:

Visit keys tab, make a new entry, click the button to generate a new account key, then click the button to register the key, then save.

Visit the certs tab, make a new cert, enter a hostname and setup a challenge/response method in the SAN list (pick a method, click +, enter the details), then save, then click issue/renew.

What you can use for the challenge depends on what you have available. If your DNS provider for your domain is listed you can probably use one of the DNS update methods, or if your server supports RFC2136 you could setup keys for the TXT records it wants to make and use the nsupdate option (this is what I prefer to do).

I would advise against attempting the webroot method directly on the firewall. You could port forward port 80 on the firewall's WAN address to a local web server and then use the webroot FTP option perhaps if you don't have any other choice.

Once you have managed to get a cert issued, go to System > Advanced, pick it for the GUI cert. Edit the cert entry in the ACME package and setup a new action for a shell command to run /etc/rc.restart_webgui, save again. Visit the general settings tab and check the box, then save.

If you want to use it for something other than the GUI, repeat the process but pick it wherever you need to use it instead (e.g. haproxy), though your update method may vary for that.

I'll write up a more thorough doc on it eventually.

awesome.. i had my dns with namecheap & wasnt able to figure out how to do NSUpdate with them. so moved it to cloudflare & it worked.

If you use cloudflare make sure the dns uses cloudflare DNS only & has a grey cloud. Grey Cloud: Records that display a grey cloud icon will bypass Cloudflare, using only Cloudflare DNS

if you have an orange cloud the auth fails. you can re-enable it after the cert is issued

doktornotor

If someone really insists on using a local webroot.

1/ Install HAproxy package.
2/ Put this to HAProxy > Files (Type - Lua script, Name: acme-http01-webroot.lua)

(or download from here)


-- ACME http-01 domain validation plugin for Haproxy 1.6+
-- copyright (C) 2015 Jan Broer
--

acme = {}
acme.version = "0.1.1"

--
-- Configuration
--
-- When HAProxy is *not* configured with the 'chroot' option you must set an absolute path here and pass 
-- that as 'webroot-path' to the letsencrypt client

acme.conf = {
	["non_chroot_webroot"] = ""
}

--
-- Startup
--  
acme.startup = function()
	core.Info("[acme] http-01 plugin v" .. acme.version);
end

--
-- ACME http-01 validation endpoint
--
acme.http01 = function(applet)
	local response = ""
	local reqPath = applet.path
	local src = applet.sf:src()
	local token = reqPath:match( ".+/(.*)$" )

	if token then
		token = sanitizeToken(token)
	end

	if (token == nil or token == '') then
		response = "bad request\n"
		applet:set_status(400)
		core.Warning("[acme] malformed request (client-ip: " .. tostring(src) .. ")")
	else
		auth = getKeyAuth(token)
		if (auth:len() >= 1) then
			response = auth .. "\n"
			applet:set_status(200)
			core.Info("[acme] served http-01 token: " .. token .. " (client-ip: " .. tostring(src) .. ")")
		else
			response = "resource not found\n"
			applet:set_status(404)
			core.Warning("[acme] http-01 token not found: " .. token .. " (client-ip: " .. tostring(src) .. ")")
		end
	end

	applet:add_header("Server", "haproxy/acme-http01-authenticator")
	applet:add_header("Content-Length", string.len(response))
	applet:add_header("Content-Type", "text/plain")
	applet:start_response()
	applet:send(response)
end

--
-- strip chars that are not in the URL-safe Base64 alphabet
-- see https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md
--
function sanitizeToken(token)
	_strip="[^%a%d%+%-%_=]"
	token = token:gsub(_strip,'')
	return token
end

--
-- get key auth from token file
--
function getKeyAuth(token)
        local keyAuth = ""
        local path = acme.conf.non_chroot_webroot .. "/.well-known/acme-challenge/" .. token
        local f = io.open(path, "rb")
        if f ~= nil then
                keyAuth = f:read("*all")
                f:close()
        end
        return keyAuth
end

core.register_init(acme.startup)
core.register_service("acme-http01", "http", acme.http01)

3/ Create a very simple http frontend on WAN address, port 80.

4/ Use this for your certificate(s) in ACME package:

[EDIT: The image host originally used in this post is dead. Fixed using cached copies of the images on another host -jimp]

reggie14

Is there any chance that this will work with Google Domain's DNS? It doesn't look Google provides a way to create txt records using their Dynamic DNS API.

Tentacruel

@jimp:

What you can use for the challenge depends on what you have available. If your DNS provider for your domain is listed you can probably use one of the DNS update methods, or if your server supports RFC2136 you could setup keys for the TXT records it wants to make and use the nsupdate option (this is what I prefer to do)..

I've been trying to get the manual method to work with he.net, but can't figure out how to generate the TXT key - While I know I need to add it manually to my DNS, is the generation of the key included in your package or is there a manual step required here?

/SJ

jimp

@Tentacruel:

@jimp:

What you can use for the challenge depends on what you have available. If your DNS provider for your domain is listed you can probably use one of the DNS update methods, or if your server supports RFC2136 you could setup keys for the TXT records it wants to make and use the nsupdate option (this is what I prefer to do)..

I've been trying to get the manual method to work with he.net, but can't figure out how to generate the TXT key - While I know I need to add it manually to my DNS, is the generation of the key included in your package or is there a manual step required here?

/SJ

That was the first method I tested. Define the domain name entry and then click issue/renew. In the green output it tells you what the content of the record should be. Add it to DNS and then wait 2-3 minutes to be sure the record is available, then click issue/renew again.

execcr

Hello,
new user here. Fresh pfsense install update to 2.3.2_1
I've installed the acme package but i have some problems with Route 53 Dns validation
The output say that:

[Mon Feb 6 17:24:12 CET 2017] Registering account
[Mon Feb 6 17:24:13 CET 2017] Already registered
[Mon Feb 6 17:24:14 CET 2017] Update success.
[Mon Feb 6 17:24:14 CET 2017] Single domain='test.sanitazedomain.it'
[Mon Feb 6 17:24:14 CET 2017] Getting domain auth token for each domain
[Mon Feb 6 17:24:14 CET 2017] Getting webroot for domain='test.sanitazedomain.it'
[Mon Feb 6 17:24:14 CET 2017] _w='dns_aws'
[Mon Feb 6 17:24:14 CET 2017] Getting new-authz for domain='test.sanitazedomain.it'
[Mon Feb 6 17:24:15 CET 2017] The new-authz request is ok.
[Mon Feb 6 17:24:16 CET 2017] Found domain api file: /usr/local/pkg/acme/dnsapi/dns_aws.sh
[color][Mon Feb 6 17:24:18 CET 2017] Error add txt for domain:_acme-challenge.test.sanitazedomain.it[/color]
[Mon Feb 6 17:24:18 CET 2017] Please check log file for more details: /tmp/acme/test/acme_issuecert.log

i checked the log and seem to fail at curl command to retriete http.header.
If i open HTTP.HEADER file in the acme domain folder (test in this case) i get:

HTTP/1.1 505 HTTP Version not supported
Date: Mon, 06 Feb 17 16:24:18 GMT
Connection: close
x-amz-id-2: 1rjTvEvOKQpJ5zruKVbddXvS15q4+I1y/+r2qirC9S8MYXm1esOQYwkOscLruZW8zzvK0+WY8BOQiy8GvYMu0rx0Uwq8WqlH
x-amz-request-id: 8B82C340F9CA158D
Content-Length: 0

any hint? Aws access ID and secret key seems ok. I've tried also to get full access to this IAM user to Route53

jimp

Route53 made some change to their service in the last few days that might have broken this client. We've had at least one other report of Route53 dyndns not working in general (not related to acme). Odds are the route53 script needs updated to match their new API/methods.

execcr

Thank you.
Just my luck. Every time i try something new, something is broken since hours or days ::)

Freshman

Hello, cert BFU here, so sorry if I won't make much sense…
Is it somehow possible to continue with certs from previous "issuing"? I have used "acme.sh" script in Ubuntu two months ago, sucefully got some acme-challenge TXT values for my (sub)domains, which I have added manually to my DNS configuration and on the second run of "acme.sh" couple files were generated (.cer, .key, ...).

I have sucesfully added generated .cer to HAproxy on my pfSense and it is now serving me my https websites through HAproxy and it was my undestanding that when the time comes I would just have to do "acme.sh --renew -d mydomain.com" to regenerate certs and manually replace cert on HAproxy.

I wanted to automate this using this pfSense package. Is it possible to continue with started process, or do I have to generate new set of TXT values and replace them at my DNS config again?

I have tried to put content of my .key file into "Account keys" tab and define same domainname on Certificates tab with Method: DNS-manual, but attempt to "Renew" ends with green "mydomain.com is not a issued domain, skip" message.

Am I doing it all wrong?

jimp

The TXT records are only valid for a few days and then they expire – you'd have to remake them when it's time to renew anyhow.

If you use the exact same list of SANs from your original cert, LE will allow it can will consider it a reissue. If you change the the list of SANs, it's treated as a new certificate. (Not too important unless you're close to their rate limits...)

Tentacruel

@jimp:

That was the first method I tested. Define the domain name entry and then click issue/renew. In the green output it tells you what the content of the record should be. Add it to DNS and then wait 2-3 minutes to be sure the record is available, then click issue/renew again.

Thanks for the response! Oddly, when I configure the manual method I get both an issue and a renew button, rather than the joined button I get if it was set to webroot, but I think that's a minor detail.

My output, however, holds no TXT entry, which is why I was getting confused


xxx.net
Renewing certificateaccount: xxx-key 
server: letsencrypt-production 

/usr/local/pkg/acme/acme.sh --issue -d 'host.xxx.net' --home '/tmp/acme/xxx.net/' --accountconf '/tmp/acme/xxx.net/accountconf.conf' --force --reloadCmd '/tmp/acme/xxx.net/reloadcmd.sh' --dns '' --log-level 3 --log '/tmp/acme/xxx.net/acme_issuecert.log'

Array
(
[path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
)
[Mon Feb 6 21:03:55 UTC 2017] Single domain='host.xxx.net'
[Mon Feb 6 21:03:55 UTC 2017] Getting domain auth token for each domain
[Mon Feb 6 21:03:55 UTC 2017] Getting webroot for domain='host.xxx.net'
[Mon Feb 6 21:03:55 UTC 2017] _w
[Mon Feb 6 21:03:55 UTC 2017] Getting new-authz for domain='host.xxx.net'
[Mon Feb 6 21:03:59 UTC 2017] The new-authz request is ok.
[Mon Feb 6 21:03:59 UTC 2017] Verifying:host.xxx.net
[Mon Feb 6 21:04:02 UTC 2017] Pending
[Mon Feb 6 21:04:05 UTC 2017] host.xxx.net:Verify error:Could not connect to host.xxx.net
[Mon Feb 6 21:04:05 UTC 2017] Please check log file for more details: /tmp/acme/xxx.net/acme_issuecert.log

jimp

I found a problem with it and pushed a fix a couple hours ago. Update the package to 0.1.8 when you see it. I put in fixes for SFTP Webroot and DNS-Manual today.

https://github.com/pfsense/FreeBSD-ports/commit/a8952d9a67c674e521f75f5c3e61d879f89d43a4
https://github.com/pfsense/FreeBSD-ports/commit/9bda224f04c361836ebd7ebf1992de20d504487b

The new package won't show up for 2.3.3 or 2.4 until new snapshots are built.

Tentacruel

@jimp:

I found a problem with it and pushed a fix a couple hours ago. Update the package to 0.1.8 when you see it. I put in fixes for SFTP Webroot and DNS-Manual today.

https://github.com/pfsense/FreeBSD-ports/commit/a8952d9a67c674e521f75f5c3e61d879f89d43a4
https://github.com/pfsense/FreeBSD-ports/commit/9bda224f04c361836ebd7ebf1992de20d504487b

The new package won't show up for 2.3.3 or 2.4 until new snapshots are built.

I see the update and giving it a shot now! Shall report back in a jiffy.

Tentacruel

Couple Caveats so far:

When you click Issue and receive the TXT record (that works lovely now thank you!) make sure you hit Renew after you have added the TXT record to your domain, otherwise you will simply generate a new TXT record.
Somehow it has generated the cert as self-signed and not via Let's Encrypt which is throwing errors in the browser. Might be because of the update, going to start from scratch and see how it goes.

EDIT: So I still had my Startcom Root CA on the firewall, which seemed to mean the Let's Encrypt CA wouldn't install. After removing that, and reissuing the cert, it's all going swimmingly.

Cheers jimp! Great little package!

yodaphone

@jimp:

I found a problem with it and pushed a fix a couple hours ago. Update the package to 0.1.8 when you see it. I put in fixes for SFTP Webroot and DNS-Manual today.

https://github.com/pfsense/FreeBSD-ports/commit/a8952d9a67c674e521f75f5c3e61d879f89d43a4
https://github.com/pfsense/FreeBSD-ports/commit/9bda224f04c361836ebd7ebf1992de20d504487b

The new package won't show up for 2.3.3 or 2.4 until new snapshots are built.

got an update to 0.1.9

github says "Sorry, this commit history is taking too long to generate."

any tip on what's new/fixed in this release?

jimp

0.1.9 was this PR: https://github.com/pfsense/FreeBSD-ports/pull/296/files

jimp

FYI-

acme pkg version 0.1.10 = Fix formatting of nsupdate options
acme pkg version 0.1.11 = Add key type and algorithm selection to nsupdate, other fixes to nsupdate
acme pkg version 0.1.12 = Add standalone HTTP and TLS server methods

Re: Standalone mode: For security reasons, Let's Encrypt requires 80 for HTTP and 443 for TLS checks. If you bind to any other port you must forward port 80/443 to that other port or the check will fail. And it goes without saying that you must allow that traffic to the firewall with rules.

Perhaps in the future it could be fancy and add a temporary rule to pass traffic to the port, but for now you'll have to add one by hand. And you'll probably want to shut down the rule afterward unless you really want to leave that port open all the time.

Mats

Two small bugs/improvement requests.

1. If you click on the questionmark in the acme plugin page - it sends you to a non existing page.
2. For each entry in the domain san list - the password is shown in clear text even in the summary - it would be better to mask it

artooro

If anyone is interested I wrote a how-to post on using this Let's Encrypt package.
https://blog.artooro.com/2017/02/16/quick-easy-lets-encrypt-setup-on-pfsense-using-acme/

It works great already. Thanks for building it!

The biggest improvement I'd like for myself is the ability to select whether an "Actions list" command is executed before or after the renewal/issue. This way a command could be used to create a firewall rule that allows ACME to verify, and then the rule can be automatically removed when finished.

efishta

I'm trying to wrap my head around making LetsEncrypt work with my HAProxy setup so that renewals go through automatically, regardless of which domain validation requests come through.

Here's the current setup on pfSense:

Ports 80 and 443 open on firewall
HAProxy reverse proxy routing both HTTP and HTTPS requests to appropriate backend servers. Only simply routingHTTP/SNI SSL passthrough, no SSL termination at this point.

I'd like to take advantage of the LetsEncrypt package, and was thinking of using the Standalone HTTP server option with a non-standard port, and then having HAProxy route the validation requests (carrying forward with automated renewals, obviously) to this Standalone Server instance.
Something like ACL (if /.well-known/blah blah blah/) use backend LetsEncrypt-standalone-server.

I am assuming that this provides a better (more secure?) option than using wwwroot, since that's the gist I got from this thread.

Now, my first question is about whether I need to set the firewall up to allow any additional ports through (say, to the Standalone Server's port from ??? where), or is this rendered unnecessary because both the proxy and the Standalone Server are on the same host (the pfSense router)?

Secondly, when creating the backend server entry for HAProxy to route to for the Standalone Server (the LetsEncrypt response/validation server), what do I use for this? 127.0.0.1:port or the router's address? 192.168.1.1:port?

Thank you for your time.