on 09-Jan-2020 15:27
This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ.
Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on SSL certificates and everything you need to know about them.
This article is divided into the following high level sections:
Please forgive me for using SSL and TLS interchangeably in this article.
Software versions used in this article:
BIG-IP Version: 14.1.2
SSL Orchestrator Version: 5.5
BIG-IQ Version: 7.0.1
OpenSSL can be used to sign a CSR. It can also be used to generate a self-signed certificate. When creating a CSR for production, you might need to use OpenSSL with a template in order to populate certain fields like the Digital Signature. This information is provided as a courtesy.
OpenSSL contains an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available.
OpenSSL can be used to create private keys, certificates and more. Here’s an example of the syntax used to create a self-signed certificate:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
Full instructions about how to use OpenSSL are beyond the scope of this article. However, the links below contain excellent information on usage:
OpenSSL - Command Line Utilities
SSLShopper- Common OpenSSL Commands
Note: If you want to create your own OpenSSL Certificate Authority the following Dev/Central Article is excellent:
Building an OpenSSL Certificate Authority - Creating Your Root Certificate
This method is generally preferred to using self-signed certificates.
Rather than reinvent the wheel, the Virtually There Blog does an excellent job of explaining the process to sign a CSR with a local Certificate Authority. Click the link below to learn more:
VirtuallyThere - Signing a CSR with your Microsoft Certificate Authority
Note: If you’re looking for information about how to setup your own local Microsoft CA see this previous blog:
VirtuallyThere - Building a Microsoft Certificate Authority for your lab
Note: the blog author has given f5 permission to include the links above.
From the Configuration Utility > SSL Orchestrator > Certificate Management > Traffic Certificate Management. Click on the certificate created earlier (my_certificate).
Click Choose File and select the signed certificate from the CA. Click OK/Open. Click Import.
Note: Using Certificate Chains or Subordinate CAs
If using Certificate Chains be sure to include all intermediate certificates in the chain. For more information on Certificate Chains, see this Microsoft article.
Follow the steps below if you already have the private key and certificate you want to use for SSL decryption.
From the BIG-IP Configuration Utility click SSL Orchestrator > Certificate Management > Certificates and Keys. On the far right, click Import.
For Import Type click Select. Different types of import options are available.
For this example, select Key. Give it a name, in this example SSL.key. You can upload the key from a local file or paste it in as text. Choose the method you prefer and click Import when done. The example below shows the local file method.
Click the name of the Key you created.
Click Import. You can upload the certificate from a local file or paste it in as text. Choose the method you prefer and click Import when done. The example below shows the local file method.
You have successfully imported the private key and certificate.
Note: most Enterprise customers will have their own local Certificate Authority (CA).
If you are creating an Inbound Topology you can use this method to create a CSR.
From the F5 Configuration Utility go to SSL Orchestrator > Certificate Management > Certificates and Keys. Click Create on the top right.
Give the certificate a name. For Issuer select Certificate Authority. Fill in the rest of the form.
Click Finished when done.
The page should look like the following. Click Download my_certificate to download it as a file. You can optionally copy the text output to the Clipboard. Download the CSR so it can be signed by your Local Certificate Authority.
Certificates generated by SSL Orchestrator need to be trusted by the client computers. If using a Microsoft Certificate Authority (CA) to sign the SSL certificates the clients will trust it automatically, assuming they are members of the same domain as the CA. If using Self-Signed certificates you need to install them in the Certificate store on all client computers.
Most Enterprise customers won't do this in production but it's often used for testing or demos. Either way, it's important to know these procedures.
Firefox has its own Certificate store. Click the icon on the top right then Preferences.
Note: Firefox version 70.0.1 was used in the configuration below.
Scroll to the bottom of the next screen. Under Security click View Certificates.
Find the Certificate on your computer. Select it and click Open.
Select the option to Trust this CA to identify websites. Click OK.
Internet Explorer/Edge and Chrome use the Windows Certificate store.
Locate the Certificate on your computer and double click it. Click Install Certificate.
Click Next at the Import Wizard.
Select the option to Place all certificates in the following store. Click Browse.
Select Trusted Root Certification Authorities then OK.
You should see a Security Warning like the following. Click Yes.
Click OK to the Successful Import message.
Microsoft has a variety of support articles and documentation for how to do this with GPO:
Distribute Certificates to Client Computers by using Group Policy
In this article we covered the most common tasks associated with SSL certificates and how to use them with SSL decryption.
The next article in this series will cover the Guided Configuration component of SSL Orchestrator.
Again with some questions 🙂 When signing CSR (for example using MS CA) is that not required to use template that is used for signing sub CA certs, so Key Usage includes those: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86) and Basic Constraints: Subject Type=CA
or it's not required and standard Web Server template can be used - means this is enough:
Enhanced Key Usage: Server Authentication
Key Usage: Digital Signature, Key Encipherment (a0)
No Basic Constraints
Just to share some thoughts: seems to me that we need at least those 3 flags:
• Digital Signature key usage (digitalSignature)
• Certificate Signing key usage (keyCertSign)
• CA Basic Constraint set to TRUE
These should be enough.
Apart from that - I see this sentence "Using OpenSSL (...) is not preferred but may be appropriate for a demo or testing purposes. This information is provided as a courtesy" - thats interesting, I think that using F5 GUI to generate CSR is a bad idea and has always been, guys from MS CA seem to hate that - I have always been forced by them to use openssl (usually by utilizing preconfigured config file as you cannot do everything by simply running openssl via CLI). Wonder if you have other experience about that.
Hi Piort and Mariusz,
I'm usually setting this up in a lab and may miss some things that are important for production environments. That being said, I'd like to provide the best guidance possible. Would you agree with the following?
When creating a CSR for production, you might need to use OpenSSL with a template in order to populate certain fields like the Digital Signature.
- Mariusz, thanks for info. Sure Off-line CRL Signing and CRL Signing are not required here - just copied values from my intermediate CA, I am lazy man 🙂
What puzzles me here is if it is really required or is rather best practice to be in line with PKI related standards. I am 99% sure that in my lab tests I used default key/cert (this one sure is not set with CA Basic Constraints) and that SSLO was still able to create forged site certs - but maybe I am wrong.
I would as well gladly hear why MS CA guys hate CSRs generated via BIG-IP GUI??? Any particular reasons for that? Not once created CSR via GUI and signed it with my MS CA (as well as TinyCA), no issues here. Did it as well using MS CA web app (CertSrv) - no problem with that.
As far as I understand how signing CSR works it's up to CA to sign it with proper "flags" - Am I missing something here?
We even have API based integration used to sign BIG-IQ (I know it's not BIG-IP, but CSR generation process is not so much different) generated CSR via MS CA - works like a charm 😎
Sure, at least I agree :-), hope my nit picking do not create impression that I do not appreciate all your hard work put into creating this series - it quite opposite, in my opinion You did great work!!
Thanks Piort, I appreciate the feedback!
, kow that I am pain in... but is there chance you will check my questions under first article in the series...
Hi Piotr, I'm trying to load balance answering your questions while still being productive in other areas. I'm in the process of adding some Cisco products to the article series.