Slides for the September 2017 pfSense Hangout video

1. Certificate Management
pfSense 2.4
June 2017 Hangout
Jim Pingle

2. About this Hangout
● Project News
● Certificate Basics
● Certificate Structure Security
● When to use pfSense
● Certificate Manager
Overview
● Certificate Authority Entries
● Certificate Entries
● Signing Request Workflow
● Certificate Revocation Lists
● Using Certificates

3. Project News
●
2.4-RELEASE is coming next week – Huge release! Lots of new things!
– https://doc.pfsense.org/index.php/2.4_New_Features_and_Changes
– Instructions for upgrading 64-bit NanoBSD to full install are available
– If installing from old hardware that won't boot memstick, see the release notes
●
Packages for 2.2.x and earlier versions are being taken offline due to security and maintenance issues
– Now that 2.4 is out, current release + one prior release covers 2.4 and 2.3, older releases are no longer officially supported
– Packages in the 2.2.x and 2.1.x set had not been maintained, many bugs & unpatched vulnerabilities
●
FRRouting package available for 2.4, 2.3.5, 2.3.4 users
– BGP, OSPF, OSPF6 configured in the GUI
– Replaces OpenBGPD and Quagga
●
SG-3100 coming soon (October ship date)
– Fast/powerful ARM device, 6 ports, four are switched Ethernet
●
XG-1537 coming soon, replaces XG-2758
– 8 core Xeon D-1537, two 10Gbit/s SFP+, two 1Gbit/s RJ-45
– https://www.netgate.com/blog/introducing-the-xg-1537-firewall-appliance.html
●
Contributing to pfSense is easier now, CLA requirement dropped
– https://www.netgate.com/blog/contributing-to-the-pfsense-project-gets-easier.html

4. Certificate Basics
● High-level basic info, will be simplified/omit some items
● Certificates provide a framework for Public Key Infrastructure
– Entities have public and private keys used to sign and/or verify data
● A certificate identifies an entity (e.g. a firewall), and has keys for encrypting communication and other purposes
– This identity consists of several values such as location information, organization information, and other identifying
information like hostnames, e-mail addresses, and IP addresses
– The identifying information, all together, forms the certificate Subject
● X.509 standard defines the format for the certificates we are discussing
– Identity Info, Public Key, Private Key
– Additional properties and extensions define how a certificate can be used (client, server, CA, IKE, etc)
● With a trust chain made from certificates, intermediates, and root certificate authorities, clients can utilize
certificates for tasks such as HTTPS validation and encryption, VPN identification and/or encryption, and other
protocols that use TLS (LDAP, EAP-TLS, SMTP, IMAP/POP3, etc)

5. Certificate Basics
● A client creates a request with its identity information and its public key, and then submits this to a
Certificate Authority (CA)
● Certificates are signed by a CA or self-signed in some cases, the signing process results in a
certificate which is delivered back to the client
– CA must have a process to identify, validate, or trust the client to know that the certificate is valid
– Can also be signed by an intermediate CA and can calculate a chain of trust
● A trusts B, B trusts C, so if D trusts A, it also trusts B and C
● If a client trusts the CA, and the CA signed the cert, then the public key for that certificate is
trustworthy for secure communication or validation
– “Root” CA certificates must be distributed to clients so they know what to trust (“Trust Anchors”), which can be
done manually for a self-signed CA or pushed out with client software like browsers, etc.
● Certificate Revocation Lists and other methods such as OSCP can direct clients to consider
certificates as no longer valid for a variety of reasons

6. Certificate Basics
● Most commonly, certificates are associated with SSL/TLS and the
infrastructure surrounding it
– CA list in the browser determines who can be trusted implicitly (“Trust anchors”)
– Server certificates are identified by certain Key Usage and Extended Key Usage
properties, and the server hostname(s) are in a list of Subject Alternative Names
– Before signing, the CA will validate the request in some way, such as:
●
Checking a file on the web server
●
Checking a DNS response
●
Manually verifying the organization by research, phone calls, and other means
– Client will verify via OSCP/CRL to determine if a certificate is still valid before trusting

7. Certificate Basics
● Certificates can be distributed in a number of formats, including:
– DER format, which is a binary format
– PEM format, which is DER format encoded with base64 in an armor string, making it easy to send via e-
mail and so it can be opened and operated on by text editors or used in plain text files
● Certificate:
-----BEGIN CERTIFICATE-----
[A bunch of random-looking base64-encoded data]
-----END CERTIFICATE-----
● Private Key:
-----BEGIN RSA PRIVATE KEY-----
[A bunch of random-looking base64-encoded data]
-----END RSA PRIVATE KEY-----
– PKCS#12, or .p12, a container/archive format which holds multiple certificates and keys in a single file,
typically including the private key, certificate, and associated CA certificate chain

8. Certificate Structure Security
● Due to the sensitive nature of certificate usage protecting not only the CA private key
but all certificate private keys is critical, but how critical depends on the specific use
case
– If a private CA for a VPN or network is compromised, an attacker could gain access to that
network
● For a small organization, a data breach may not give access to much that an attacker might want, but a
larger or more secretive org has more to lose
● For a small organization, making a new CA and certs is relatively easy but for a large organization, a new
CA is a sizable task
– If a public CA is compromised, an attacker could impersonate any web server on the Internet
– If a server certificate private key is compromised, an attacker could impersonate that server or
intercept communications that would otherwise be secret
– If a client certificate private key is compromised, an attacker could gain access to resources
such as a VPN or Wireless network, and possibly intercept communications

9. Certificate Structure Security
●
Some companies will keep the system which holds their private CA offline/air gapped
– While this is ideal security, it is inconvenient and cumbersome to manage
●
For many, keeping the CA on a secure limited-access system, such as a firewall or central
authentication server, is good enough as a security vs convenience compromise
●
The certificate itself and the public key for a CA, server, or client are open information, no special
protection required
– For a VPN it is still better to not give out more info than necessary, so it is worth keeping everything private
where possible
●
How to distribute certificates and private keys to servers and clients?
– Generate the certificate on the target so the private key never leaves that system
– Physical handoff (USB thumb drive given in person after verifying identity)
– Secure and authenticated communications protocols (ssh/scp with key-based authentication)
– Smart cards (Yubikey and similar tokens), key is stored on the card and cannot be extracted, but user must
know the PIN/Phrase which can be given in a different, secure, method

10. When to use pfSense
● If key is security is so important, why use pfSense to manage certificates?
– The firewall is secure when properly configured
● On an average network, if the firewall is compromised the attacker would already be able to do most anything they would gain by getting
access to the certificate keys
– Few people have access to the firewall
– Typically the firewall is in a physically secure location
– The certificates and keys for server usage have to be on the firewall anyhow (e.g. OpenVPN, HAProxy)
– More convenient to use than other certificate management solutions (e.g. easyrsa or manually using OpenSSL)
– Enables use of the OpenVPN Client Export Package
● Why not?
– It is still connected to the network, and thus could be theoretically compromised by a remote attacker
– No current means of automating the certificate generation process for large batch operations
– If your organization is under strict standards or policies that dictate where a CA key may be stored
●
Decide on your own where the security vs convenience tipping point makes sense for your network

11. Certificate Manager Overview
● Located at System > Cert. Manager
●
Can create or import CA, certificate, and CRL entries
● Can sign certificate signing requests
●
Can handle intermediate CA chains
● Can export CA, certificate, and CRL entries, keys, and even .p12 archives that bundle the
CA, Certificate, and private key together
●
Entries in the Certificate Manager can be used wherever certificates are required on
pfSense services or packages
● Certificates can be associated with users for services which use multi-factor authentication
– Currently only OpenVPN requires user+certificate in this way

12. Certificate Authority Entries
● System > Cert Manager, CAs tab
● Shows a list of CA entries with some details
– Descriptive Name is the custom local name given to the CA to identify it in pfSense
– Internal indicates whether or not the CA private key is present
– Issuer shows if the CA is self-signed or has an external issuer (e.g. an intermediate)
– Certificates counts how many entries on the Certificates tab are issued from a CA
– Distinguished Name shows the CA subject and start/end dates
– In Use shows if, and where, a CA entry is used in the pfSense GUI
– Actions has buttons to perform actions on a CA entry: Edit, Export CA Cert, Export CA Key,
Delete (if not in use)
● Click + Add to add a new entry

13. Importing a Certificate Authority
● Imports a CA created elsewhere
● Open the PEM format CA Certificate and Private Key in a text editor
● Descriptive Name can be any name to identify the CA
● Method: Import an existing Certificate Authority
● Copy/Paste the PEM format CA Certificate into the Certificate Data field, including the armor strings
● For an internal CA
– Copy/Paste the PEM format Certificate Private Key, including the armor strings
– Enter the Serial for next certificate, it must be an integer and higher than any other serial for certificates issued
from this CA, otherwise it could lead to a serial collision and problems revoking certificates later
● This number may be tracked by whatever software generated the CA, e.g. easyrsa maintains a serial file with a binary value, see
https://doc.pfsense.org/index.php/Using_EasyRSA_Certificates_in_2.x
●
If this is not known, check the serial number of the last certificate issued by the CA
● For an external CA, leave the private key and serial number blank

14. Internal Certificate Authority Entries
● Creates a new self-signed CA entry capable of signing certificates
●
Descriptive Name can be any name to identify the CA
● Method: Create an internal Certificate Authority
● Key Length determines the strength of the private key, 2048 is a good default
●
Digest Algorithm should be at least SHA256 unless there is a legacy requirement (e.g. outdated equipment
that can only use SHA1)
● Lifetime is how long the CA will be valid, since it is internal, 10 years should be OK
●
The remaining fields identify the physical location of the firewall or organization, and can be set however you
like, and on 2.4 this also includes punctuation and international characters in most fields
●
The Common Name is not typically a hostname for a CA, but an internal name such as “internal-ca” or “vpn-
ca”
●
The Create an intermediate Certificate Authority method works identically, but you also select an internal
CA which will sign this CA, turning it into an intermediate

15. Certificate Entries
● System > Cert Manager, Certificates tab
● Shows a list of Certificate entries with some details
– Descriptive Name is the custom local name given to the cert
– Issuer shows the CA that issued the certificate, if present on the firewall
– Distinguished Name shows the certificate subject and start/end dates
● Click the “i” to see more detail such as the serial, digest, Key Usage, and Extended Key Usage
properties
– In Use shows if, and where, the entry is used in the pfSense GUI
– Actions has buttons to: Edit, Export Cert, Export Key, Export .p12, Delete (if not in use)
● Click + Add to add a new entry

16. Importing Certificate Entries
● Imports an existing certificate created and signed by an external source
● Open the PEM format Certificate and Private Key in a text editor
● Descriptive Name can be any name to identify the Certificate
● Method: Import an existing Certificate
● Copy/Paste the PEM format Certificate into the Certificate Data field,
including the armor strings
● Copy/Paste the PEM format Certificate Private Key, including the
armor strings

17. Internal Certificate Entries
● Creates and signs a new certificate using an internal CA
● Descriptive Name can be any name to identify the cert
●
Method: Create an internal Certificate
● Cerficiate Authority is the internal CA that will sign this certificate (CA must have private key present)
● Key Length determines the strength of the private key, 2048 is a good default
● Digest Algorithm should be at least SHA256 unless there is a legacy requirement (e.g. outdated equipment that can only use SHA1)
● Lifetime is how long the cert will be valid, since it is internal, 3650 days (~10 years) should be OK for internal use
● The remaining fields identify the physical location of the certificate user or device
– Default values will be carried over from the CA for convenience but they can be changed at will
– Can be set however you like, and on 2.4 this also includes punctuation and international characters in most fields
●
The Common Name is typically a fully qualified domain name (e.g. host.fqdn.com) or username
●
Certificate Type sets the Key Usage and Extended Key Usage properties of the certificate, primarily allowing peers to determine if a certificate
should be valid for use as a server, IKE intermediate, and so on
– Pick User Certificate for user or client device certificates
– Pick Server Certificate for server usage such as OpenVPN server, IPsec remote access, HTTPS server, EAP, and similar purposes
●
Alternative Names is a list of identifiers (Subject Alternative Names, or SANs) for the certificate, and the Common Name is considered the
first Alternative Name automatically
– These entries can be hostnames/usernames, IP addresses, e-mail addresses, or URIs

18. Signing Request Workflow
● Rather than creating and signing an internal certificate, you can also with with Certificate Signing Requests
(CSRs)
● Typical Flow:
– Client creates a CSR and private key
– Client submits the CSR to a CA, but does NOT send the private key (it’s private)!
– CA signs the CSR, setting additional properties during the signing process
– CA sends the signed Certificate back to the client
– Client uses the certificate and their original private key, along with the CA certificate and any intermediates as usual
● Interface to create a CSR is the same as creating an internal certificate, but there is no CA choice or lifetime
● Choose Create a Certificate Signing Request for the Method
● The Certificate Type and Alternative Names list can be set but are ultimately determined by the CA
– Values set by the user are generally ignored but can be set to express a preference
● Once a CSR has been created, it can be exported for submission to an external CA

19. Signing Request Workflow
● Once a CSR is signed by an external CA, click the pencil to edit the CSR
and paste in the final certificate data and the entry will be promoted to a
normal internal certificate
● Alternately, a CSR may be signed by an internal CSA after creation
– Click +, then Pick Sign a Certificate Request for the Method
– Choose the CA and CSR from the drop-down menus, or paste in the PEM
format CSR and Private Key for an external CSR
– Enter a lifetime and digest to sign the certificate request with
– Pick the Certificate Type and enter the SANs to add to the certificate signing
request

20. Certificate Revocation Lists
●
A Certificate Revocation Lists (CRL) lists certificates which should no longer be considered valid, for
example if a copy of the certificate was lost or the private key was compromised in some way
●
After a CRL is defined, it must be selected to be used in some way (e.g. on an OpenVPN server),
except with IPsec which automatically locates and uses CRLs for a given CA
●
System > Cert Manager, Certificate Revocation tab
●
The page lists existing CRLs
– Name, Internal, Certificates, In Use work similar to the other tabs
● Each CA is listed on the page, with a + Add or Import CRL button next to each
●
Click + next to a CA to add a CRL for it
●
To import a CRL, choose Import and paste in the PEM format CRL data, including the armor text,
give it a name and make sure the correct CA is selected
– You cannot add to an imported CRL, only import a new copy!

21. Certificate Revocation Lists
● Creating an internal Certificate Revocation List
– Set a name and ensure the correct CA is selected
– Pick a lifetime for the CRL, the default of 9999 is OK, or something shorter
– Leave the Serial at 0 or enter a custom serial number if you like
– Click Save to return to the CRL list
● To revoke a certificate:
– From the CRL list, click the pencil to edit an existing internal CRL
– Choose a Certificate from the list – it must be present on the firewall!
– Pick a Reason from the list to reflect why the certificate is being revoked
– Click + and the certificate is added to the CRL
● The original certificate can be removed from the certificate manager after adding it to a CRL, a
copy is held on the CRL for future use by the CRL

22. Using Certificates
●
In pfSense and its packages, there are several places where a certificate in the certificate manager can be utilized, such
as:
– Base: WebGUI HTTPS, OpenVPN SSL/TLS, IPsec (IKEv2, Mutual RSA), Captive Portal HTTPS
– Packages: HAProxy, FreeRADIUS for EAP, Squid for Peek/Splice or MITM or Reverse Proxy, NET-SNMP
●
Certificates can also be made on pfSense and exported for use by any other SSL/TLS application that trusts the CA
●
For OpenVPN…
– The OpenVPN wizard can create a CA and Certificate for you, pre-selecting the basic properties needed to run a VPN
– The OpenVPN Client Export Package bundles the certificate in various ways depending on the type of download requested by the user
●
Remember, for use with external devices and software (browsers, VPN clients), the target device must trust the CA,
which usually means importing the CA in some way
– OpenVPN has the CA in a file alongside the certificate(s)
– IPsec or Squid MITM require the CA be imported into the client operating system or related software
– See previous hangouts on Remote Access VPNs and on Squid for info on how to import a CA appropriately
●
For the GUI and other HTTPS server uses by a browser (not squid), consider using the ACME package to generate a
certificate which is valid and trusted by browsers already without additional intervention, see the previous hangout on the
ACME package for details

23. Conclusion
● Questions?
● Ideas for hangout topics? Post on forum, comment on the blog
posts, Reddit, etc