FMC/FTD 10 ACME Cert

[brian1stamper1]

Just curious if anyone has made this work with FTD/FMC 10.0?  I decided to try it in lab just to see using Lets Encrypt and following the document here:
https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/usecase/VPN/using-acme-certificates-ravpn-policies-fmc.html

I'm using a custom domain name that resolves to the IP of the outside interface of my firewall.  I'm using that interface as my Authentication Interface as well as my Source Interface in the Cert Enrollment although I've probably tried this every different way with every different interface.  A packet capture run on the outside interface when I try this shows ssl coversation with  https://acme-v02.api.letsencrypt.org.  It also shows the http get request for /.well-known/acme-challange/randomstring resulting in an HTTP/1.1 200 OK.  

My result is always the spinning in progress for a period of time followed by failure and it stating the generic:
Possible Recommended Actions:
1. Ensure the following to make sure of connectivity to the ACME Server from the Firewall Threat Defense
- Route is added to the ACME Server via the source interface
- If ACME Server is referred with hostname/FQDN/ALT FQDN, configure DNS at Threat Defense Platform Settings to resolve hostname
2. Ensure that the ACME Server and the Firewall Threat Defense are in time-sync by configuring the same NTP Server.

I ran the debug crypto ca acme but didn't yield anything that would be giving me a failure reason. 
Just curious if anyone else has played with this or made it work?

[Ben Weber]

Hey @brian1stamper1,

One thing to check: are there any upstream devices that might be handling the ACME challenge instead of the FTD?

The HTTP/1.1 200 message may be coming from an ISP modem, router, CPE, or any other upstream device before it reaches the FTD.

If another device that is not the FTD is responding, then obviously the ACME challenge will fail because the correct ACME token won't be served.

Check the data path from the FTD to the ACME server and that might help you fix your issue 🙂

[brian1stamper1]

There would not be.  The firewall itself has the public IP that the FQDN of the cert request resolves to. 

[Marvin Rhoads]

If there's an upstream firewall, are you allowing both http and https inbound to your lab firewall's outside interface? The ACME enrollment uses http for a brief moment while enrolling.

I did get it to work in my lab environment FYI. 🙂

[brian1stamper1]

There is no upstream firewall in this case.  The firewall requesting the cert has the public IP and directly connects to the internet.  

[brian1stamper1 · Accepted solution]

I figured this out!!  I think Cisco needs to update this documentation as they have a critical step missing.  In the below portion of the document they have you add the Cert to the firewall.  What isn't listed or is maybe assumed is that you have to add the Root to the firewall first.  You can see it in the background of the pic in Step 5. Stands to reason and makes sense that would need to be there.  However, no where in the document does it actually tell you to do that other than in this screenshot it shows it. 
I remember having to do this setting up SAML auth to Entra for VPN as well and I'm pretty sure if I remember right they tell you in that how to document to add this root cert before adding the cert from Entra for the SAML/IDP.  
Hopefully this helps someone else following the document or Cisco updates it.  

[Marvin Rhoads]

I agree it's a bit tricky. I had just re-built mine and recreated an ACME enrollment successfully for the first time since originally doing it during 10.0 beta testing.

If you read the "General Prerequisites" section it does say "Enroll an ACME CA certificate, a manual CA-only certificate that authenticates the ACME server, on the device." It shows a screenshot of the cert enrollment but not the part about making it a trustpoint on the device. It would be better if that was explicitly called out in the instructions.

I submitted feedback to the Cisco documentation to that effect. Hopefully they will update it.

[Rashmy Abraham]

Hi @Marvin Rhoads, 

Thank you for submitting the feedback for this document. 

I have updated the "Prerequisites for Using ACME Certificates" topic with a sample ISRG root certificate.
https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/usecase/VPN/using-acme-certificates-ravpn-policies-fmc.html#prerequisites-for-using-acme-certificates
Please do let me know if this is the info that you wanted.

Thanks, 
Rashmy

[Marvin Rhoads]

Thank you @Rashmy Abraham - that's clearer now.

I have been asking in another thread if it is possible to have the CA certificate included in the ACME certificate trustpoint. So far it appears that is not possible. This results in an incomplete chain being presented for the TLS connections.

Reference: https://community.cisco.com/t5/network-security/ama-secure-firewall-new-features-automation-and-troubleshooting/td-p/5374154

[stpsucks]

I wonder if they'll add a way for it to pull down full-chain bundles in the future so a new intermediate CA is included. you can sometimes get away with signing with root CA's but it's definitely not best practice. otherwise you'll be stuck babysitting the validity for your intermediates.

[kelwingmen]

I had a bit of a struggle with this one too. I already had the ISRG root certificate enrolled on the FTD, but I also selected it on the actually ACME enrolment, and then it fails. just leave the selection box blank and it will say "manual CA Certificate"