ACMEv2 SSL with Google?

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: totusmel.com

I ran this command: So many things...see below for details

It produced this output: A lot...see below for details

My web server is (include version): Various, trying to get a wildcard cert to work with pfSense to do SSL reverse proxying for various servers

The operating system my web server runs on is (include version): Mostly Linux

My hosting provider, if applicable, is: Google

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): pfSense's ACME Certificate generation

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): It's complicated, but I think 1.32.0

Hi Everyone,

I have a domain that is hosted through Google that I would like to setup a wildcard certificate, but going through the ACME certificate creation process in pfSense gives me the following result result:

[Fri Nov 11 06:48:12 PST 2022] Register account Error: {"type":"urn:ietf:params:acme:error:externalAccountRequired","detail":"External Account Binding is required for new accounts. See https://tools.ietf.org/html/rfc8555#section-7.3.4 for more information.  request-id: PcoI/gxPD2IIqc78EbvgqA==","requestID":"PcoI/gxPD2IIqc78EbvgqA=="}

I went to RFC 8555: Automatic Certificate Management Environment (ACME) and determined that I needed to register an account somehow with Google to accomplish this.

I eventually stumbled upon https://cloud.google.com/blog/products/identity-security/automate-public-certificate-lifecycle-management-via--acme-client-api to I thought start some of this process, which then led me to certbot to get things registerd.

The certbot wanted specific keys from Google to work though, so I eventually got into Google Cloud and ran the following [some info obscured]:

gcloud projects add-iam-policy-binding project-name --member=user:email-address@gmail.com --role=roles/publicca.externalAccountKeyCreator
gcloud alpha publicca external-account-keys create
Updated property [core/project].
Updated IAM policy for project [project-name].
bindings:
- members:
  - user:email-address@gmail.com
  role: roles/owner
- members:
  - user:email-address@gmail.com
  role: roles/publicca.externalAccountKeyCreator
etag: tag
version: 1
Created an external account key
[b64MacKey: eab-hmac-key
keyId: eab-key]

I then ran the following on Ubuntu rasberry pi [again, some info obscured]:

uquevedo@raspi:~$ sudo certbot register --email email-address@gmail.com --no-eff-email --server "https://dv.acme-v02.api.pki.goog/directory"  --eab-kid "eab-key" --eab-hmac-key "eab-hmac-key"
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at https://pki.goog/GTS-SA.pdf. You must agree
in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: yes
Account registered.

I thought this was enough to get things registered, but that doesn't seem to be the case? Because when I go to generate a key again using the Google ACMEv2 in pfSense, I still get the following:

[Sat Nov 12 07:26:15 PST 2022] Register account Error: {"type":"urn:ietf:params:acme:error:externalAccountRequired","detail":"External Account Binding is required for new accounts. See https://tools.ietf.org/html/rfc8555#section-7.3.4 for more information.  request-id: PcoI/gxPD2IIqc78EbvgqA==","requestID":"PcoI/gxPD2IIqc78EbvgqA=="}

Navigating Google's myriad of services and products is so confusing and I'm not sure I've setup anything properly?

Has anyone gotten this working through Google for the wildcard SSL certificates with the Google ACMEv2 key creation?

Any help or advice would be greatly appreciated!

2

pfSense is probably using a different ACME client under the hood than Certbot, so it tries to register an account for itself: it can't use the account in Certbot.

Looking at Packages — ACME package | pfSense Documentation the pfSense ACME client might not even support EAB.

Also, let me ask just so we're on the same page, do you want a certificate from Google? Or a Let's Encrypt cert on Google Cloud?

6 Likes
3

Correct; it uses acme.sh, which does support EAB--but that doesn't mean its implementation in pfSense supports EAB.

5 Likes
4

For security and automation concerns, I strongly recommend using acme-dns to manage the DNS authentication for your wildcard certificate.

You can read more about this solution here:

3 Likes
6

That sounds like a single point.
Where is that point?
That should be the only one that needs an ACME client and the wildcard cert.

If indeed there are multiple points that require an ACME client and their own individual wildcard certs, I would split that into separate requests and troubleshoot them independently.

3 Likes
7

Thanks for all of the responses, I was out and about yesterday, so I wasn't able to respond as quickly as I'd have like to.

I don't want a certificate through Google, I want to leverage the dns based verification using an API for a Let's Encrypt certificate, which apparently I need to get setup through Google Cloud? It seems that other DNS providers have an easier setup for this but I'd rather keep the things I have at Google.

I'm wondering if I could ssh into the pfSense box and issue the appropriate commands on the cli and the pfSense be able to save and use that? I thought that if I did this verification/account creation on my rasberry pi, that would take care of the account creation and I could continue on through pfSense, but that doesn't seem to be the case.

I will look into this, but I'd really like to have this setup on the one type of appliance system I have so I can set it and kind of semi forget it.

From what I've read and watched through various how-to videos, the reverse proxying would all be done through the pfSense box. I have a lab environment too, that is isolated from my main network, so I'd have to do something with the other pfSense box I have between my main network and the lab network.

Thanks again and I'll be looking into the links referenced above.

Any other thoughts would be greatly appreciated!

1 Like
8

Then external account binding (EAB) isn't required at all. So I'm wondering why you get that error. What CA is "selected" in pfSense?

3 Likes
9

I may have misspoke, it's under the key generation section for which ACME server to register with, this is what I'm presented:

Screenshot 2022-11-13 at 7.12.14 AM
Screenshot 2022-11-13 at 7.12.14 AM1694×210 45.9 KB

When I click on the register acme account is when I get the error I mentioned above.

If I select the Let's Encrypt ACME servers, I don't have this issue at all.

I would need to register with the Google Production ACME v2 to be able to be able to do what I'm trying to do, right?

I'm reading about the acme-dns, and I'm intrigued, but that sounds like it would be run on one of my other systems that I'd need to expose in a read only manner to verify TXT records...but I don't see how I can integrate that into my pfSense system? I'm trying to keep this all on the pfSense system to leverage some of the features there.

Any other thoughts would be greatly appreciated!

10

And you wanted a Let's Encrypt certificate, right? So what's the issue with that?

Not if you want a Let's Encrypt certificate, no you wouldn't. Google has its own CA, just as Let's Encrypt is a CA. They're different.

Also, it seems you've managed to generate a Let's Encrypt wildcard certificate for your domain yesterday already: crt.sh | totusmel.com

3 Likes
11

Draw us a map.
To explain the lay of the LANd(s).
I'm hearing multiple networks and possibly multiple pFsense devices.
[I'm lost]

3 Likes
12

Sorry, really new to all of this, and I thought that I needed to select Google as the ACME server.

Yes, I did create a Let's Encrypt certificate, I just thought that I needed to go through Google to do this to be able to use an API call to update the domain to make this work properly. I'm now seeing that likely isn't the case?

Here's a very general setup of my network:
My_Network
The lab network is isolated from the main network, so I imagine that whenever I get this working, I'd need to get a certificate setup on that system too to provide certificates for that network since I I'd have to do a reverse proxy on that network.

I think at this point, it's pretty clear that I don't need to keep pursuing this Goolge API setup since I can do the verification a few different ways. Looking into the acme-dns, it sounds like I'd have to allow specific access to acme-dns to present the needed TXT record if I'm understanding things correctly? If that's the case, I think I'd need to open up a way for an outside DNS entry request to be verified on a system I'm running acme-dns on? Do I have this right?

1 Like
13

Not using the Google ACME API anyway. Which API you do need to install your LE certificate is unknown to me.

And that all is hosted at Google?

14

No, this is all local. The internet connection is through my ISP.

The zone totusmel.com is hosted through Google Domains...again, which is why I thought I needed to go through Google for this to work, at least for the API aspect to update things. I think now that is no longer the case.

The method for doing the verification of the Let's Encrypt is the manual DNS method with the TXT record, which is why I was trying to come up with some way to automate this since I believe the TXT record needs to be updated every time the certificate gets renewed.

For the acme-dns method, I do have a dynamic host setup through the Google domain that I could reinstate and have that point back to my network and open the specific port that is needed to so that what acme-dns produces could be accessed. Would that be a recommended method?

Again, thank you for all of the responses and clarification, there is some base documentation for this, but all of the help putting this all together is very appreciated!

1 Like
15

So when you said "My hosting provider, if applicable, is: Google", you meant your DNS service provider? Usually, with "hosting provider" the company that's hosting the website is meant. Or where your VPS/physical server is located. Not DNS.

There are ACME client DNS plugins for Google Cloud DNS available. Certbot has one and I'm sure acme.sh also has one.

What do you mean by "dynamic host setup"? With acme-dns usually one would just add a CNAME or NS resource record for the _acme-challenge label which would redirect to a specific FQDN or nameserver where acme-dns is listening.

1 Like
16

My apologies, I misunderstood the question.

Should I bother pursuing this since I don't technically have to go with Google Cloud DNS? I'd ideally like to do this all through pfSense so that certificate process is contained on that system since I'd like to do the reverse web proxy through that system and I'm pretty sure the certificate needs to be stored there too.

The dynamic host entry has a bit of software running on a system I run so that when my ISP IP address changes, it updates the A record associated with that IP address change. I thought that the acme-dns needed to run on a system that was reference-able through the domain record that I control. I was thinking I would setup the cname to point to that dynamic dns hostname so that it would always be reachable and fulfill the need of acme-dns.

17

I'm not familiar enough (not at all to be honest) with pfSense to be able to tell you what its capabilities are unfortunately.

Ah yes, "dynamic DNS" it's what I'd call that. If your IP address changes, you'd need to be able to update whatever is pointing to your acme-dns instance indeed.

1 Like
18

As you say, your DNS hosting is with Google Domains, not Google Cloud DNS--those are two different things. So let's review a few things:

  • You want a cert from Let's Encrypt. That means you'll need to register for an account on that CA, and only on that CA--Google's CA is not in play here.
  • You want a wildcard cert. That means you'll need to complete the DNS challenge--when you issue the cert, and every time you renew the cert, you'll need to create DNS records with certain unique (i.e., they'll be different every time) values.
  • Your DNS hosting is with Google Domains, which acme.sh (and therefore pfSense) doesn't support. You therefore aren't able to make the necessary DNS updates automatically.

So, to make this work, there are a few options:

  • You could manually complete the DNS challenge every time you need to renew the cert. Possible, but not ideal to say the least.
  • You could change to using a different DNS host. Cloudflare has a robust, well-supported API, and is free for this purpose. pfSense supports Cloudflare out of the box.
  • You could use acme-dns, as recommended up-topic. It's intended to be self-hosted, which would mean running a local server and forwarding TCP/UDP port 53 there. However, its author also operates a public acme-dns server which you could use, and that wouldn't require you to install or run any software locally.

Note that if you use the public acme-dns server, its operator could, if he chose, issue his own certs for your domain--there's almost always a trade-off between convenience and security. But here's how you'd do that.

Register an account

You'll first need to register an account. Do this by running curl -s -X POST https://auth.acme-dns.io/register | python3 -m json.tool. You'll get output that looks like this:

{
    "username": "0b854d23-8a21-448e-b87d-43464bb66036",
    "password": "QeDNgypiQY1zSU9kqFN-TwGfo84xDNHRh3o7f9i2",
    "fulldomain": "a0e624ef-2f35-48b9-8eef-bbd5770694f7.auth.acme-dns.io",
    "subdomain": "a0e624ef-2f35-48b9-8eef-bbd5770694f7",
    "allowfrom": []
}

These are the credentials you'll need to create a static DNS record, and to set up pfSense. Do not simply use the credentials; you should generate your own set.

Create a DNS record

You'll now need to create a CNAME DNS record for _acme-challenge.totusmel.com pointing to the fulldomain value you received (a0e624ef-2f35-48b9-8eef-bbd5770694f7.auth.acme-dns.io in the example above). You only need to do this once; it doesn't change.

Configure pfSense

Now configure pfSense to use this. If it needs the full URL, you'd enter https://auth.acme-dns.io/update; I seem to recall a recent change where it didn't need the full URL any more so you could leave off /update. Username, password, and subdomain would be copied from the credentials you received.

Issue the cert

You're now ready to go; you can issue the cert through the pfSense web UI and it should renew it for you automatically.

5 Likes
19

Thank you so much for summing up my situation so well, that's exactly what I am facing and want to do.

I'm going to read up more on the acme-dns. While I like the idea of having a public server do the work for me, I don't like the idea of not having as much control.

I have an idea to leverage my dynamic dns configuration for a potential acme-dns setup using all of the above info.

I think I'm on the right path now and thanks for all the pointers and more importantly patience with all of my quesions!

2 Likes
20

Just came back real quick that my setup is a bit more complex than what I'd need to go through to get to work for running acme-dns locally, so I went with the auth.acme-dns.io option.

Just for reference, it's the following option when selecting the method and no, there's no need to dow the full URL path:

Screenshot 2022-11-13 at 7.27.18 PM
Screenshot 2022-11-13 at 7.27.18 PM1876×282 22.7 KB

1 Like
21

Just for info, I believe Google are actively working on an API for Google Domains ACME challenges being one of the primary use cases, it's not in beta yet though.

3 Likes