csr attributes that are required or optional

 

CN	Common   Name	This is the fully qualified domain name (FQDN) that specifies the server’s exact location in the Domain Name System (DNS). For example, a component with hostname webBridge1 and parent domain example.com has the fully qualified domain name webBridge1.example.com. The FQDN uniquely distinguishes the component from any other components called webBridge1 in other domains.	Required, see notes below
O	Organization or Business name	Usually the legal incorporated name of a company. It should include any suffixes such as Ltd., Inc., or Corp. Use “” around the attribute if more than one word, e.g. “Example Inc.”	Optional
OU	Organizational unit or Department name	For example, Support, IT, Engineering, Finance. Use “” around the attribute if more than one word, e.g. “Human Resources”	Optional
L	Location	City or town. For example, London, Boston, Milan, Berlin.	Optional
ST	Province, Region, County or State	For example, Buckinghamshire, California. Do not abbreviate. Use “” around the attribute if more than one word, e.g. “New Jersey”	Optional
C	Country	The two-letter ISO code for the country where your organization is located. For example, US, GB, FR.	Optional
An email address		An email address to contact the organization. Usually the email address of the certificate administrator or IT department.	Optional
SAN	Subject Alternative Name	From X509 Version 3 (RFC 2459), SSL certificates are allowed to specify multiple names that the certificate should match. This field enables the generated certificate to cover multiple domains. It can contain IP addresses, domain names, email addresses, regular DNS host names, etc, separated by commas. If you specify this list you must also include the CN in this list. Although this is an optional field, the SAN field must be completed in order for XMPP clients to accept a certificate, otherwise the XMPP clients will display a certificate error.	Required   for XMPP server certificates or if a single certificate is to be used across   multiple components.  See note below. Note: XMPP server is not supported from version 3.0

issue importing or renewing cert on palo alto firewall

Replacing/renew an existing wildcard cert

You need the .pfx cert with private key bundle

cert password

name the new cert "cert_name_of_existing_cert" or something new "cert_may_2026"

In palo select the cert

click import

choose pkcs12, choose the .pfx file

enter the password

import and commit

Don't forget update the SSL profile (a bit below certs) with the new cert 

Test the GP web interface

When trying to import a cert with the private key bundled you get an error:

Import of certificate and private-key CERT-NAME failed. private key doesn't exist for csr.

Importing the signed cert with the same name as the CSR doesn't work. Panorama adds cert_ to the front of the name

You need to port cert_ in front for example if cert is called CERT-NAME you put cert_CERT-NAME

CSR import

Import the CA bundle if not done already

If you make duplicates will have to delete on CLI

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000kHyVCAU&lang=en_US%E2%80%A9

tick your pending CSR

click import 

give the same name as your csr request 

select the pem file

PEM file format

ok

commit

Importing SAML cert

Create new cert and make it active 

Delete old/inactive cert

Wait a few minutes for cloud to do its thing

Download the .xml files

In palo delete old certs and commit

Going into SAML IDP provider

Import 

Untick validate checkbox

This will import the cert and create a saml profile

User your new saml profile in your auth sequence 

Test connection to GP etc

install wildcard cert on palo alto firewall

Global protect portal and gateway should be setup

Get customer to get DNS record created eg globalprotect.domain.com

Point the record at the global portect portal IP (Network -> Global Protect -> Portals)

Download the wildcard cert and root/chain cert from the cert vendor (.crt format). The windows .p7b format is no good. The chain bundle cert usually publicly available. The wildcard will need to be downloaded via a login may need to get it from the customer.

Install wildcard cert on palo alto firewall

Global protect portal and gateway should be setup

Get customer to get DNS record created eg globalprotect.domain.com

Point the record at the global portect portal IP (Network -> Global Protect -> Portals)

Download the wildcard cert and root/chain cert from the cert vendor (.crt format). The windows .p7b format is no good. The chain bundle cert usually publicly available. The wildcard will need to be downloaded via a login may need to get it from the customer. Example vendor chain location:

https://certs.godaddy.com/repository

Import vendor root/chain cert bundle

Device -> certificate management -> certificates 

Click import 

Give name eg "vendor-ca-root-chain-bundle"

Select the bundle file "bundle-g2.crt"

Leave everything else and click ok

Import wildcard cert

This can be imported in a few methods (.crt) (.pfx) if its PFX you will need to include the password

Certs should look like this

 

Create SSL/TLS profile

Device -> Certificate Management -> SSL/TLS Service Profile

Name "SSL-TLS-PROFILE"

Min version: TLSv1.2

Max version: Max

Attach SSL/TLS profile to global protect portal and GW

Network -> GlobalProtect -> Portals 

Click the GP_Portal

Authentication tab 

Under server authenticaiton / SSL/TLS service profile

Select your "SSL-TLS-PROFILE" from the drop down

Configure the URL used for portal/gateway in the portal

Network -> GlobalProtect -> Portals

Click the GP_Portal

Agent 

Add the CA root and chain cert (optional to tick install in root cert store)

 

Now click on GP_Agent_Config -> External

You will need a DNS -> pub IP record setup with the external DNS vendor

Fill in the DNS name for the Gateway

 

Add the SSL-TLS profile to the gateway as well

Network -> GlobalProtect -> Gateways

Click the GP_Gateway

Authentication tab

Under server authenticaiton / SSL/TLS service profile

Select your "SSL-TLS-PROFILE" from the drop down

Change IP to URL

Go Portal - GP settings - Agent - Agent config - External

Change external gateway IP to URL

Testing

Do not forget to commit your changes

You may need to restart the GP client

Test web browse to https://globalprotect.domain.com

Test connecting the GP client to globalprotect.domain.com

convert pfx to separate private key and cert files with openssl

n this article I’m going to show you the commands you need to convert your .PFX Certificate file to a seperate certificate and keyfile. This article can come in handy when you need to import your certificates on devices like Cisco routers/loadbalancers etc. where you probably need to import the certificates and keyfiles in plain text (unencrypted). My tool of choice (but there might be others) is OpenSSL for Windows, which can be downloaded here

So after you installed OpenSSL you can start it from it’s Bin folder. I’d like to put OpenSSL\Bin in my path so I can start it from any folder. Fire up a command prompt and cd to the folder that contains your .pfx file. First type the first command to extract the private key:

openssl pkcs12 -in [yourfile.pfx] -nocerts -out [keyfile-encrypted.key]

What this command does is extract the private key from the .pfx file. Once entered you need to type in the importpassword of the .pfx file.  This is the password that you used to protect your keypair when you created your .pfx file.  If you cannot remember it anymore you can just throw your .pfx file away, cause you won’t be able to import it again, anywhere!.  Once you entered the import password OpenSSL requests you to type in another password, twice!. This new password will protect your .key file.

Now let’s extract the certificate:

openssl pkcs12 -in [yourfile.pfx] -clcerts -nokeys -out [certificate.crt]

Just press enter and your certificate appears.

Now as I mentioned in the intro of this article you sometimes need to have an unencrypted .key file to import on some devices.  I probably don’t need to mention that you should be carefully. If you store your unencrypted keypair somewhere on an unsafe location anyone can have a go with it and impersonate for instance a website or a person of your company.  So always be extra careful when it comes to private keys! Just throw the unencrypted keyfile away when you’re done with it, saving just the encrypted one.

The command:

openssl rsa -in [keyfile-encrypted.key] -out [keyfile-decrypted.key]

Again you need to enter an import password. This time you need to enter the new password that you created in step 1.  After that you’re done. You decrypted your private key. In the folder you ran OpenSSL from you’ll find the certifcate (.crt) and the two private keys (encrypted and unencrypted).

Update 07-07-2014:

In some cases you might be forced to convert your private key to PEM format. You can do so with the following command:

openssl rsa -in [keyfile-encrypted.key] -outform PEM -out [keyfile-encrypted-pem.key]

From

https://www.markbrilman.nl/2011/08/howto-convert-a-pfx-to-a-seperate-key-crt-file/

SSL cert decorder

https://www.sslshopper.com

Digicert have an application you can download for windows too

openssl can be used on linux

SAN certs

Standard SSL cert = web.domain.com

Wildcard cert = *.domain.com
Unlimited sub domains.

SAN cert = up.domain.com
                    to.domain.com
                    five.domain.com
                    in-these.domain.com
                    certs.domain.com
                   
Up to 5 sub domains
Generally used with phone systems
Some companies use them to cover their standard sub domains

webmail.domain.com
mx.domain.com
remote.domain.com

read csr information in linux

Extract information from the CSR

$ openssl req -in shellhacks.com.csr -text -noout

Verify the signature

$ openssl req -in shellhacks.com.csr -noout -verify

Whom the certificate will be issued to?

$ openssl req -in shellhacks.com.csr -noout -subject

Show the public key

$ openssl req -in shellhacks.com.csr -noout -pubkey

installing certificates on the cisco ASA

Wildcard cert

GoDaddy steps

What you need

• Purchased wildcard cert
• Login details for godaddy site
• Access to public DNS provider to create URLs and TXT record
• Access to ASA/ASDM
• Access to domain controller/server where you can install openssl

Saving the private key

When setting up a new wildcard godaddy gives you the option to save the CSR and the private key. You should save these. Client might have created it already. You can look on the domain controller or email server for it and see if you can export it from mmc -> certificates snap in. If it can't be found or lost you can rekey the cert, contact godaddy for steps. I believe the rekey can cause issues if the cert is already installed somewhere as now the private key won't match. Try to avoid this.

DNS provider

You need to verify a wildcard with a DNS TXT record, need to contact DNS provider. Godaddy provide instructions.

You can check the TXT records here https://dnslookup.online/txt.html

Once the set is setup you can download the zip file. Choose the "other" option

You may need to get "vpn.domain.ie" pointing to public IP of ASA

Create combined PKCS12 / PFX file with Openssl

Now use openssl to bundle private key + wildcard cert into one file with a password.

You may need to install openssl (http://gnuwin32.sourceforge.net/summary.html)

Openssl command:

pkcs12 -export -inkey MY_PRIV_KEY.key -in WILDCARD_CERT.crt -out STAR_DOMAIN_COMBINED.p12

You will be asked for password here, save this password.

Good idea to install the PFX on the customer domain controller for safe keeping. 

Install as exportable

Choose the computer account

Choose the  personal cert store. 

You can find the cert later in start -> run -> mmc -> add certs snap-in.

ASA install

Now install the STAR_DOMAIN_COMBINED.p12 on cisco ASDM.

ASDM -> Configuration -> Certificate Management -> CA Certificates -> Add -> CA cert (from zip file downloaded from godaddy)

Now click on Identity Certs -> Add  

Choose "Import the identity cert from a file (PKCS12)

Enter the password you entered at the openssl step

Select the STAR_DOMAIN_COMBINED.p12

Click "Add certificate"

Apply to interface. 

Configuration -> Advanced -> SSL settings

Click on outside interface -> Edit button and select cert

Testing

Go to your anyconnect URL. 

Confirm the cert is setup with chome -> developer tools -> security or this one:

https://www.sslshopper.com/ssl-checker.html

This is the process of installing a wildcard cert if you have one:
https://www.tunnelsup.com/adding-a-wildcard-ssl-certificate-to-a-cisco-asa/

Get the following
The password used to export the certs (If password not setup – you can generate this by using OPENSSL app)
The certificate private key (pfx) file (in pem format)
The wildcard certificate (in pem format)
The intermediary certificate (in pem format)

Customer should have access to their Trusted root CA portal where you can download most files. The customer should have the private key (pfx) file and the password for it. The trusted root CA does not hold that. Its generated when the cert is used for the first time.

In the past we have found the customer import the private key onto a webserver but didn't save the private key. We were able to export the private key from the web server. Had to open mmc add certificate snap-in and add for the computer account.

Download and install win32/63 openssl to convert your cert into the correct format.
See https://support.citrix.com/article/CTX136444

Use openssl to create the pkcs12 file. This is done by bundling the private key + the wildcard cert.

Openssl command:
pkcs12 -export -inkey MY_PRIV_KEY.key -in WILDCARD_CERT.crt -out STAR_DOMAIN_COMBINED.p12

openssl pkcs12 -export -in CERT.crt -inkey PKEY.key -certfile sf_bundle-g2-g1.crt -out BUNDLE.pfx 

Make sure to save the password you enter. Now this file can be imported into ASDM.

Can be done here https://www.sslshopper.com/ssl-converter.html
However its advised you don't upload your certs to a third party use openssl on your own PC

If you have an old/expired wildcard cert you can remove it now, otherwise you might get an error when trying to assign the new one to an interface.

Add the CA cert (pem - plain text BEGIN CERT etc)
Configuration > Device Management > Certificate Management > CA Certificates
Add the pkcs12 cert (pfx) with password
Configuration > Device Management > Certificate Management > Ident Certificates
Assign the cert to the interface (advanced -> SSL)
Configuration > Device Management > Advanced > SSL

This is the process of creating an ident cert and getting it signed by your CA, they send you a signed cert that you can install.
https://www.tunnelsup.com/adding-an-ssl-certificate-on-an-asa/

Ident certs
Create ident cert (config -> Firewall -> Advanced -> Certificate management -> Ident cert)
Add new (create a new key pair if you need to)
Click select button and fill in the details
In this example the url I have bought the cert for is is remote.domain.ie
subject-name CN=remote.domain.ie,OU=IT,O=Customer,C=IE,St=Leinster,L=Dublin
Export cert and send to CA
CA sends back signed cert
Install signed cert
Apply to interface.


After installing
Export the cert + key from ASDM and install the .pfx in their windows server so they don't lose it. Don't forget to record password.
 
More on certs

.csr
This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. The actual format is PKCS10 which is defined in RFC 2986. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate (which includes the public key but not the private key), which itself can be in a couple of formats.

.pem
Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. Confusingly, it may also encode a CSR (e.g. as used here) as the PKCS10 format can be translated into PEM. The name is from Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.
.key This is a PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one. In Apache installs, this frequently resides in /etc/ssl/private. The rights on these files are very important, and some programs will refuse to load these certificates if they are set wrong.

.pkcs12 .pfx .p12
Originally defined by RSA in the Public-Key Cryptography Standards, the "12" variant was enhanced by Microsoft. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Openssl can turn this into a .pem file with both public and private keys: openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes
A few other formats that show up from time to time:

.der
A way to encode ASN.1 syntax in binary, a .pem file is just a Base64 encoded .der file. OpenSSL can convert these to .pem (openssl x509 -inform der -in to-convert.der -out converted.pem). Windows sees these as Certificate files. By default, Windows will export certificates as .DER formatted files with a different extension. Like...

.cert .cer .crt
A .pem (or rarely .der) formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.

.p7b
Defined in RFC 2315, this is a format used by windows for certificate interchange. Java understands these natively. Unlike .pem style certificates, this format has a defined way to include certification-path certificates.

.p7s
Looks like this one is used for signing emails

.crl A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration. You can sometimes download them from CA websites.
In summary, there are four different ways to present certificates and their components:

PEM Governed by RFCs, it's used preferentially by open-source software. It can have a variety of extensions (.pem, .key, .cer, .cert, more)

PKCS7 An open standard used by Java and supported by Windows. Does not contain private key material.

PKCS12 A private standard that provides enhanced security versus the plain-text PEM format. This can contain private key material. It's used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.

DER The parent format of PEM. It's useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used by much outside of Windows.

x509 (can be .pfx and .der .cer .crt)

Usually in some directory like C:\webserver\apache\cert

Drop in the new server.crt (just cert file)

Drop in server.key (psk) in the same directory 
Restart webserver

MII means base64 encoded you will often see this with x509 certs

Most common openssl commands
https://www.sslshopper.com/article-most-common-openssl-commands.html

cryptography, encryption and certificates

Cryptography, encryption and certificates

Data at rest (setting in memory or on hard disks)
Data in motion (moving through the network)

Managemnet plane - ASDM/web interface / CLI
Control Plane - Routing protocols, STP etc
Data plane - the packets passing etc

We need to protect both

Encryption - used to keep data confidential at rest or in motion
Keys - Data is encrypted with a key. The key is also used to decrypt the data.
Cipher text - data that has been encrypted
Clear text - the unencrypted data
Symmetrical vs Asymmetical
Symmetrical - 1 key is used to encrypt and decrypt the data (DES, 3DES, AES). Used for bulk encryption data on disks etc.
Asymmetrical - 2 keys known as a key-pair, higher CPU overhead, used with authentication.
data encrypted by key1 can only be decrypted by key2
data encrypted by key2 can only be decrypted by key1
key1 = private key
key2 = public key (public keys can be exchanged, then we encrypt with private key)
RSA, DSA


Hash/HMAC - Integrity, making sure it hasn't been manipulated along the way (MD5,SHA). We hash the data (math algorithm) which gives us a result known as a digest.
If we check the the hash and if it has been changed they will know. HMAC is used to secure the hash by putting a secret key in the HMAC. HMAC stops man in the middle attacks.

Digital signature - encrypted has of the private key is the digital signature
To digitaly sign you need public/private key pair setup
Data generate a hash
Encrypt the hash with the private key (digital signature)
Data+Encrypted hash is sent.
Data is hashed
Encrypted hash is decrypted with the public key from the sender
Compare the hash we calculated with the decrypted hash and make sure they match

pem format - files that end in the suffix ‘.pem’ or ‘.key’ or '.crt' usually are in this format. If you open the file in notepad it will have BEGIN CERT and END CERT and the top and bottom.

pkcs12 format - files often end in .pfx or .p12. The file will be unreadable by notepad (encrypted) it is created by combining the private key and the ca cert(intermediate) with a tool like openssl. Digicert prvides a tool for windows.