There was a question on the Spiceworks forum this week and I suggested simply trusting the certificate to stop a certificate error, and got asked.
Could you please let me know how to import the downloaded certificate
I was surprised to find I’d not really covered this as a stand-alone subject so here we go.
Solution: Trust a Certificate
Firstly, If you can go and spend a few minutes reading the following article Digital Certificates Explained especially the Golden Rules of Certificates section. Every IT Pro and Developer should have a basic grasp of certificates and how they work. It will take you less than 5-10 minutes to read that article and will save you struggling in future.
Now you’ve read that article above, you know to trust a certificate you must trust the CA that issued the certificate. With the askers problem it was getting the certificates from a VMware vCentre server, which is easy as peas, because it gives you the option to download them on the main screen like so;
Note: If you download the certs they come in a zip file, extract them out of that zip file, (or you won’t see “Open As” on your right click menu when you want to import the certificate(s)).
Now normally you will get four files, two are CRL (Certificate Revocation List) files we won’t be needing those but the two remaining files (the ones with the .crt extension) right click > Open With > Select Crypto Shell Extensions (Note: If you don’t do this the file may open in notepad, and just show you the certificate as a PEM file).
Import or Trust a Certificate
Install Certificate > Select “Local Machine” > Next > Select “Place all certificates in the following store” > Next.
Finish > OK.
You can now see I don’t have any certificate errors, (if yours still does, check the Golden Rules of Certificates (see above) , one of them still broken).
I can’t See a Root Certificate! (or Root CA Certificate) In some cases you may need to select the Certification Path tab select the CA certificates (there may be a few in the ‘chain’ look at each certificate and import them one by one, going up the chain all the way to the root certificate at the top.
Related Articles, References, Credits, or External Links
This post was written because of a follow up question in this article. How do you go about convert certificates? Sometimes you get a certificate issued or sent toy you that is in a format you cannot import, so you need to convert it. Regardless of whether you are a mac/Linux user or a Windows user, the tool that I find best to use is OpenSSL.
OpenSSL is built into macOS to use OpenSSL on Windows you need to download, install, then run the openssl.exe (usually form command line, but you can also run from PowerShell (Note: See comment below if you intend to use PowerShell).
Linux Note: To install OpenSSL, different flavours of Linux differ e.g. sudo apt-get install openssl should work in most cases.
Windows Note: Remember to change to the directory in which OpenSSL.exe resides before executing the following command(s). See the Windows Examples for clarification.
Solution : Convert Certificates
The most common form of issued x509 certificates have a .crt or a .cer extension, CRT is based on DERDistinguished Encoding Rules, and the other (CER) is based on PEMPrivacy Enhanced Mail. OpenSSL can convert form one to the other. Note: Below I’ve shown the process on my mac and a Windows PC to illustrate the process is the same.
Convert Certificates CRT to CER
Use the following Syntax to convert from CRT to CER format. (Change the values in Red to match your source and destination certificate locations).
[box]
openssl x509 -inform PEM -outform DER -in /Users/petelong/CERTS/Source-Certificate.crt -out /Users/petelong/CERTS/Output-Certificate.cer
[/box]
Convert Certificates CER to CRT
Use the following Syntax to convert from CER to CRT format. (Change the values in Red to match your source and destination certificate locations).
[box]
openssl x509 -inform DER -outform PEM -in /Users/petelong/CERTS/Source-Certificate.cer -out /Users/petelong/CERTS/Output-Certificate.crt
[/box]
Convert Certificates CRT to PEM
Disclaimer: This is a bit of a misnomer, because .crt certificates are already in PEM format. You can simply open a .crt file and view it as a PEM file. Use the following Syntax to view a CRT in PEM format. (Change the values in Red to match your source and destination certificate locations).
[box]
Linux / macOS
cat /Users/petelong/CERTS/My-Certificate.crt
Windows
type C:/Certs/My-Certificate.crt
[/box]
Then copy the ‘text’ as shown in the examples above. DO NOT include any additional spaces (as shown above). And you have a PEM file you can paste this into a text editor and save it with a .pem extension if you need to ‘send’ it somewhere.
Can I simply rename .crt to .pem (YES YOU CAN)
Convert Certificates CER to PEM
This is slightly more complicated as .cer files are in DER format, if you try and open one with a text editor you will simply see gobbledegook. So you need to convert it into PEM format with he following syntax.
[box]
openssl x509 -inform DER -outform PEM -in /Users/petelong/CERTS/My-Certificate.cer -out /Users/petelong/CERTS/PEM-Certificate.pem
[/box]
Once that’s done (as above) you can simply open the .pem file in a text editor or cat (mac/Linux) or type (Windows) the content.
Converting Certificates (PowerShell)
Be Aware: When calling OpenSSL form a PowerShell command, you need to prefix the command with a ‘dot slash’ see the examples below for clarification.
Related Articles, References, Credits, or External Links
From setting up PKI environments, to migrating them, and a myriad of errors and problems in between, we have a lot of content on PNL referring to digital certificates and PKI. I’ve dealt with these technologies a lot over the past 20+ years and I’m always surprised how frightened of digital certificates people are. So in the space of a few minutes I’ll try and give you a basic understanding of what PKI is, how that relates to Digital certificates, then finish off with a few certificate ‘Golden rules‘.
Solution : Digital Certificates Explained
You will see I use the terms PKI environment, and Certificate Services and interchange those two things a lot, Certificate Services is the name of the Microsoft ‘Role” that provides Certificate Services. If you simply want to setup certificate services, then use the following link.
Before you understand certificates, you need to have a basic understanding of Public Keys, and Private Keys, how this key pair is used, and what Asymmetric Cryptography is (bear with me the maths might be mind boggling, but the concept is simple).
Public Key
The public key is shared openly and is used to encrypt messages or data. It is associated with a user (or entity) and can be freely distributed to anyone. Its primary function is to ensure confidentiality by allowing others to encrypt messages that only the owner of the corresponding private key can decrypt.
Private Key
The private key is kept secret and is known only to the owner. It is used for decrypting messages or data that have been encrypted with the corresponding public key. The private key is crucial for ensuring the authenticity and integrity of the data because only the person with the private key can decrypt and access the information.
Digital Certificates Explained: How These Keys are Used for Encryption
Encryption
1. Sender obtains the recipient’s public key and uses the recipient’s public key to encrypt the message.
2. Encrypted message is sent to the recipient.
Decryption
3. The recipient, (who possesses the corresponding private key), can then decrypt the message.
The strength of the security lies in the complexity of the key pair. Asymmetric cryptography is based on mathematical principles, making it computationally infeasible for someone to calculate the private key even if they have the corresponding public key. This makes it a secure method for tasks such as secure communication, digital signatures, and online transactions.
Digital Certificates Explained: Use of Keys and Certificates
Public Key Infrastructure (PKI) is a framework that manages digital keys and certificates. it requires the following:
Key Pair Generation: The process begins with the generation of a key pair (the public and private keys) for a user or entity. As shown above the public key is shared openly, and the private key is kept secret.
Certificate Authority (CA):A Certificate Authority is a trusted third party (public) or you own (private) system for authenticating digital certificates. in a PKI system.
The user’s public key is combined with other information (such as identity details and time stamps,) and then signed by the CA to create a digital certificate.
Digital Certificates: A digital certificate is a data structure that binds a public key to an individual, device, or service. It includes the public key, and information about the entity, the digital signature of the CA, and other metadata. So the digital certificate serves as a way for others to verify the authenticity of the associated public key and ultimately the identity of the entity.
Certificate Lifecycle: Certificates have a defined lifecycle, including issuance, and expiration. Note: They can also be revoked before expiration for example if compromised, or if the associated private key is lost.
Usage in Secure Communication
When parties want to communicate securely, they exchange their digital certificates. So just like the example above, the sender encrypts data with the recipient’s public key, which they get from the certificate that the receiver has published publicly, ensuring only the recipient, with the corresponding private key, can decrypt it.
Note: Digital signatures, created using the sender’s private key, can also be attached to messages to ensure authenticity and integrity. The recipient can verify the signature using the sender’s public key.
Digital Certificates Explained: Golden Rules Of Certificates
You must trust the CA that issued (authorised) the Certificate.
Every certificate has a CA that issued/approved it you NEED TO TRUST that CA, there are several trusted Certification Authorities that are built into your computer, and these are updated regularly with normal updates. this is why if you self-sign a certificate or build your own CA – then you may need to manually get people to trust your CA before they will be trusted. Also Certificate Authorities are hierarchical (they can have parent CAs) these form a CHAIN, and you need to be able to see that chain and trust ALL the CAs in that chain, (all the way back to the Root CA).
Above on my (current) site certificate you can see it was issued by a CA called RapidSSL, and that CA was authorised by a Root CA called Digicert Global Root G2. This means my certificate was signed by an intermediate CA (sometimes called and Sub CA).
The Certificate needs to be In Date
Certificates a have a date they were issued and a date when they will expire, If you are not at a point in time between these two dates, then you will not trust the certificate. (Note: this can happen if the internal clock/date on YOUR machine is incorrect).
Note: A Certificate that is in date can also be revoked. This is done by the CA, which publishes a list of certificates that have been revoked, (that your computer can check.)
The Common Name (CN) and/or Subject Alternative Name (SAN) needs to be correct.
In times gone by, the certificate CN had to be correct, but more modern browsers will require BOTHCommon Name and Subject Alternative Name to be correct. these are fields in the certificate that hold the name of the entity for example mine is www.petenetlive.com (that is the Common Name) This is the address (or FQDN) that is typed into the browser window to get to the site that presents this certificate.
Note: That means if you are putting a certificate on ‘something‘ be that a website, or a device, the NAME needs to be both correct, and resolvable by the person (or entity) that you want to trust it, e.g. if the common name was www.petes-site.com and you needed to type in https://www.petenetlive.com to get there, it would not be trusted (even if both names resolved to the correct IP address!)
You need to trust the ‘Algorithm‘ that signed the certificate.
This is a more recent development, I mentioned above that there’s some very complicated maths going on, as time moves on the mathematics needs to get more complicated, as computers get more powerful to maintain security. So older methods of signing have been depreciated, if a certificate is using technology that’s been depreciated it will also not be trusted.
Here’s an example of what happens when the signature algorithm is not trusted.
Error seen when attempting to open a web page that’s been secured by https with a certificate.
Your Connection isn’t private
Attackers might be trying to steal your information from {host-name} (for example, passwords , messages or credit cards)
Solution : ERR_CERT_WEAK_SIGNATURE_ALGORITHM
I had not seen this error for a while, and I was surprised I was seeing it now. It’s because the certificate that’s been used on the website is using SHA1 as its signature algorithm.
If you have purchased this certificate you will need to get it reissued, but chances are this is a self-issued certificate form Certificate Services. If that is the case, you need to update your certificate services form SHA1 to SHA256.
Error seen when attempting to open a web page that’s been secured by https with a certificate.
Your Connection isn’t private
Attackers might be trying to steal your information from {host-name} (for example, passwords , messages or credit cards).
Solution : ERR_CERT_COMMON_NAME_INVALID
This error confused me GREATLY because I generated that certificate, and I was pretty certain the common name was correct, so I double checked.
The truth is this error is VERY MISLEADING, the problem has nothing to do with the certificates Common Name (for the uninitiated, the Common Name or CN is a value within a certificate, that usually holds the ‘resolvable name’ of the website you are visiting i.e. on my certificate (above) you can see that’s www.petenetlive.com).
The certificate giving me the error in the picture above THERE NOTHING WRONG WITH THE COMMON NAME. The real reason that you are seeing this error is because there’s no entry in the Subject Alternative Name (SAN) value in the certificate. So I created a new certificate and copied that same value into both the common name and subject alternative name fields – like so.
If your certificate is publicly signed, then you will need to go back to the certificate vendor and have the certificate reissued with a subject alternative name. However, I issue these certificates internally from my own Certificate Services, so I just needed to add that like so.
Related Articles, References, Credits, or External Links
