LetsEncrypt integration

[Brett_Hobbs]

Hi,

While I know most would use an issued SSL certificate it would be great if PANOS supported LetsEncrypt for requesting SSL certificates for things like the management interface and GlobalProtect.

[btorresgil]

Hello,

Your concerns about security are important to us. Let me try to explain our logic around how this works and we can discuss if this meets your needs.

On first issue of the cert, acme.sh accepts the FW credentials via a temporary environment variable. However, to renew the cert and deploy it automatically, acme.sh needs to have the FW creds to deploy the cert, so we leverage the acme.sh credential storing mechanism to store the FW user/pass.  acme.sh does store all the creds in clear text (PAN-OS and DNS host passwords alike) in a file called `account.conf`. The location and permissions of this file can be controlled through acme.sh settings, so it can be stored in a way that makes it inaccessible to other users.  In fact, this is the default.

acme.sh (and other LetsEncrypt clients like certbot) also store the private keys for the certificates after they are issued, and these private keys are not password protected or encrypted. They are stored in the same secure location as the `account.conf` file, inaccessible to other users.

We recommend that a dedicated letsencrypt username be created on the firewall with only import and commit permissions. The deploy script is designed to commit only the changes made by this letsencrypt user, so it won't interfere with any uncommited changes that exist during the certificate renewal.

We decided that with the minimal permissions available to the firewall user, the secure nature of the acme.sh account credential file, and the fact that there are other valuable secrets like DNS host credentials and private keys stored in the same secure way, it would be acceptable to store the FW credentials according to the acme.sh standard.

If you disagree or this doesn't meet your needs, we're open to other methods of handling credentials during a certificate renewal.  Please let us know what would work better for you.

Thanks!

 -Brian

[btorresgil]

One other note since you mentioned a DMZ host. The nature of acme.sh is to verify domains without the need for incoming connections. This is a huge advantage, and a necessary feature for automated certificates on a firewall. This feature allows acme.sh to live on hosts anywhere in your network that has access to the internet and the firewall, which means it doesn't need to live in a DMZ or accept incoming connections of any kind. You can therefore place the acme.sh host on a secure vlan that does not allow anything inbound.

[fjwcash]

This is very handy, thanks for the link.  Now I just need to figure out how to make it work with our dehydrated setup.  🙂  Although, since we do everything via Panorama, this might not be as useful; I'm not sure I'd want an automated push to 52 firewalls ...

[panguyen]

I want to make a correction in how acme.sh stores the credentials. acme.sh will base64encode the credentials and then save them.

[hshawn]

This is interesting, I am glad I found this thread because it appears this acme.sh script may be what works for my lab setup however reading through the docs I do not see an option that would work for a PAN firewall that is hosting a GP VPN (ports 80 and 443 are in use). There is mention in this thread about this working without needing inbound connections but I am not seeing that outlined here: https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert

I will comb through the docs more when I get off home tonight but am I missing something? Is this still in the works or should this give me a Let's Encrypt cert with auto renewal for the firewall (without needing a server behind the firewall exposed to the internet) as it is today? 

Use case:  Generate a valid cert for the GP VPN portal domain.

[Alex_Samad]

I wonder if that is by DNS ?

[panguyen]

Thanks for your interest. I'm currently writing a how-to which will explain how to get this deploy to run successfully.  To get this to work with out opening ports is to use the acme.sh automatic dnsapi feature.

https://github.com/Neilpang/acme.sh/wiki/dnsapi

I have tested this with the CloudFlare option and it works.

[hshawn]

Thanks for the info! I have been researching and I believe I am out of luck since I use Google Domains (not gcloud) and they do not have an API. I may have to move to another service to take advantage of the script.

[panguyen]

You could export your DNS to GCloud DNS. Then you can leverage the Google Cloud DNS API.

[CLIq]

@btorresgil well, its ok for labs as workaround but for production I would expect a role that would be restricted as much as possible so not much damage could be done with that user.

[PLA_HT]

1) If you're currently using Let's Encrypt certs with PAN-OS and your workflow does not look like the above, can you briefly describe it?

Not using LE with PAN-OS. 

2) Is your desired end goal that PAN-OS runs Let's Encrypt natively? If not, what is your desired end goal?

Yes. LE native.

3) In between the end goal and now, would you want a stop-gap solution?

No thank-you.

4) If you want a stop-gap solution, what form should it take? A standalone executable / script? Ansible module? Terraform resource? Tie-in to an existing Let's Encrypt client, such as certbot or acme.sh?

No thank-you. Waiting for LE native solution. 

Thanks, PLA ☮

[panguyen]

I wanted to share an article I wrote on how to use LetsEncrypt Certs with PAN-OS.

Costless, Automated, Trusted Certificates on Palo Alto Networks Firewalls 

[hshawn]

For me the issue is that if you are running a GP portal on port 80/443 then these methods for getting an LE cert won't work. Even NATing port 80 into another server that will only work when accessed by IP (hostname will try to use https) 

Changing the ports that GP runs on is not a very elegant solution. I think having functionality built into PANOS that will take the GP portal into consideration might be helpful. For example in my case it would be nice to have a cert on my lab portal.

[fjwcash]

I use an LE cert for our GP Portal.  And the Web UI for each firewall.  The only thing we don't use LE certs for is the rest of the GP infrastructure (gateways and clients).  That's all done using the self-signed, trusted ca cert on the portal.

We use DNS-based checks for creating the LE certs.  No web server required.  Currently using dehydrated (python script) as it was the first one that I found that supports DNS challenge and hook script support.  Renewing the certs is completely automated.  The only manual part is copying the cert to the firewall, as I haven't gone through all the testing to get it working via the XML API.  🙂

[panguyen]

@fjwcashYou may want to check out this article on how to completely automate the renewal process.

Costless, Automated, Trusted Certificates on Palo Alto Networks Firewalls