Let’s face it, certificate management is a pain and unfortunately it is only going to get worse now that we’re limited to a maximum certificate validity of one year. That means you will need to go through this process once a year for every server, router and firewall you are responsible for.
The focus of this article is on Cisco Firepower Threat Defense, specifically managed with a Firepower Management Center (FMC). This should provide you a good reference which you can go back to whenever needed instead of memorizing the process or documenting it yourself.
If you are familiar with an Adaptive Security Appliance (ASA) then this process will feel somewhat similar although the steps are in a slightly different order.
Identify the public Certificate Authority (CA) intermediate certificate which your CA of choice will be using to sign your Certificate Signing Request (CSR).
In the case of Digicert, this is often the publicly available G2 but it depends on the product as well such as Domain Validation, Extended Validation, and also which sub-brand you are receiving your signed certificate from. For example, Thawte might be signing it instead of Digicert proper. I recently discovered this while providing assistance to a client who purchased their certificate through a broker – SSLStore. Throughout the entire process, SSLStore said Digicert. When we received the certificate however it became clear that it was actually signed by Thawte who is owned by Digicert.
This wasn’t a big deal, except we had to restart the process because of the order in which you complete the steps in FMC vs. the order completed on an ASA.
Once you have identified the correct intermediate certificate you are ready to truly begin. From the top menu bar select “Objects” > “Object Management.” This will take you to object management.
Next from the left menu bar select “PKI” > “Cert Enrollment.” This will display any existing Cert Enrollments which may already exist on your FMC. Ignore these for the time being, we’re going to create a new enrollment.
Click on “Add Cert Enrollment” to create a new certificate enrollment.
Name your certificate enrollment, it is recommended you name this something unique to the certificate/URL in question. In our example we are naming this www.skyline-ats.com.
Within the enrollment dialogue box you will also see below the name/description a few tabs. We’ll start with the first. “CA information”
Our chosen Enrollment Type is “Manual.” Other options are “SCEP,” “Self Signed Certificate” and “PKCS12 File.” Once you have selected “Manual,” an empty field appears “CA Certificate *.” This is where you will paste your CA intermediate certificate.
Now you are ready to move to the next step in the enrollment. “Certificate Parameters.” Click on “Certificate Parameters” and fill in your information.
Include FQDN: – I generally recommend “Custom FQDN” be selected here.
Fill in the FQDN for which the certificate is to be generated. In our case, www.skyline-ats.com.
Include Device’s IP Address: Enter the IP address of the interface which this certificate will be bound to in the future. This is typically the “Outside” interface but your naming convention may vary to suit your needs.
Common Name (CN): This is the all important location which web browsers use to compare the certificate to the URL for which you are connecting to. This MUST match your FQDN. In our case www.skyline-ats.com.
Organizational Unit: This is typically something along the lines of “IT” or “MIS” or whatever you like really. It’s not that important.
Organization: This is a bit more important, especially for Extended Validation certificates. This should match the identifying information you have on file with the CA.
Locality, State, Country Code should all be fairly self explanatory. Email should be the responsible person handling the certificate and should also be on file with the CA.
Do not Include the Device’s Serial Number.
Now click on the “Key” section of the enrollment. The defaults are acceptable for most environments. Click “Save.”
You now have your Certificate Enrollment created and are ready to generate a CSR. If you do not see your enrollment which you created, you clicked cancel. It should appear in the PKI objects under Certificate Enrollment as shown in the example.
From the top menu bar select “Devices” > “Certificates.”
When the “Certificate page loads, click “Add” in the top right corner. A new window will appear as shown in the figure below.
Click add. The certificate will appear below as requiring an import.
Click on the ID. A warning window will appear indicating a new CSR will be generated. Click “Yes.”
This will bring you to the “Import Identity Certificate” displaying your newly generated CSR which you need to have signed by your CA. Copy the text contents from Beginning / End. You may close this window by clicking “Cancel.” The contents of the CSR will not be lost and will not change when you come back.
Once you have received the signed certificate from the CA you may return to the “Import Identity Certificate” window and browse to import your signed certificate followed by clicking “Import.”
Once you have successfully imported the signed certificate, you are ready to bind the trust-point to the interface desired. From the top menu bar, click on “Devices” > “Remote Access.”
Select your Remote Access policy which you created before starting this process. Click on the Pencil icon to edit the policy.
Move to the “Access Interfaces” section of the policy where you will see your interfaces listed. Select the interface you want to bind the trust-point to by clicking on the pencil.
Within the “Edit Access Interface,” the bottom menu “Trustpoint” select the trust-point you created and imported the signed certificate to. Click “OK” to finish.
Save your policy and you’re all finished. Just deploy your policy as usual now.
For more information on IT training, visit our course catalog at https://catalog.skyline-ats.com/Catalog/index.php