ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.
Just to add to the thread.
Yes I would like to use letsencrypt with PA.
No I don't want to manage the certs in PA. why - current management sucks - renew a cert with SAN attributes and they get lost - support tell me thats just how it is and I shouldn't be using the PA for cert management so (double checked with SE ..)
I do like current have a script for auth and distributing certs.
I would mind if somebody here could port the scripts to insert into PA.
By PA I mean Panorama which would then distribute it to the other PA's
so I wouild have a place holder name of say LE1 which could then assign to a PA management interface.
My script would renew the LE1 cert and then insert into PA (via api ?) which would overwrite the current LE1 and then somehow push from panorama to the PA's
Having this integration would be amazing.
We manage around 100-odd PA-220's for small clients all with GP.
To answer you questions:
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?
We aren't using it because of the high maintenance.
2) Is your desired end goal that PAN-OS runs Let's Encrypt natively? If not, what is your desired end goal?
100% Natively would be the goal.
3) In between the end goal and now, would you want a stop-gap solution?
Depends on how complex.
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?
Anything - but depends on how complex.
any update here?
1) I have a webserver behind the Palo for which I want to enable inbound ssl decryption, I use letsencrypt certs for this.
2.) endgoal is only to not have to reimport the cert into palo every x weeks, an integration into the autocertbot would be good
4) standalone script or better tied into certbot
@panguyen wrote a LetsEncrypt integration for PAN-OS into the acme.sh client. The Pull Request is up for review here:
While the PR is getting reviewed and merged, you can use the integration by simply downloading the deployment file (deploy/panos.sh) into your own acme.sh installation. Here's a link to the file: https://github.com/Neilpang/acme.sh/pull/2614/files#diff-6ca80cd0349982033417d0bcd9b6952e
I know many people use Certbot, but we wanted a solution for internal and external firewalls that could be 100% automated, and we couldn't find a way to do that with Certbot. Acme.sh has many API-based domain verification capabilities that match well with the use case for internal firewall certs and automatic deployment. If anyone knows a viable way to integrate with Certbot, let us know.
Happy to answer any questions, and enjoy your free, auto-deployed firewall certificates!
ok, so the deploy of this is done automatically and only when a new cert has been issued...
but this stores a superuser account name and password in cleartext... should be mentioned or better yet store only the api key accessible only by the user executing the command or something like that..
final solution should be somewhat secure, an exposed DMZ-host which might have a vulnerability giving superuser access to the firewall which can then open up access to the rest of the network?
must be a better way
EDIT: giving API access for import and commit seems to be enough (still allows to import new config and gain full access this way but...)... now if it were possible to only store the api-key and store this in a safe way it would at least be an interim solution until something can be created that allows nothing but import certificates
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.
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.
This is very handy, thanks for the link. Now I just need to figure out how to make it work with our dehydrated setup.
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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!