Not sure why, but I spend a large amount of time working on certificate problems, being asked questions about certificates, or fixing certificate problems. For certs that are web presented, back in the days of IE I could simply do this.
For those sniggering at my IE use – I typically work on client’s sites where I can’t go round installing browsers that are not terrible! Now that was all fine, now we (finally have got rid of IE (mostly)). How do I do the same with Edge?
I was losing my temper trying to fix my test Exchange server certificates today. Because I could not find the same information with Microsoft Edge. As it transpires the information is there, Microsoft have just done their best to hide it!
Edge View Certificate Information: Solution
You need to click the ‘padlock’ > Connection is Secure > Then click the small Icon at the top > the certificate details are then displayed on two tabs, the information is not as well formatted as it used to be, but it’s all there.
Related Articles, References, Credits, or External Links
The certificate here at PNL expired over the weekend, I got a new one and installed it. All appeared to be fine until I did an online check to make sure it was OK.
The server’s certificate chain is incomplete
Solution
I had this problem once before, back then I was using Apache and CentOS7, and things were a little different, (now I’m using NGINX and Ubuntu 18.04). Essentially you see this error because you have bought a ‘cheap‘ SSL certificate. There’s nothing wrong with that per se, but they tend to be issued from an ‘Intermediate CA‘. Again there’s nothing wrong with that either, but to improve your score you need to ‘Embed‘ the intermediate certificate, into your SSL certificate, (or all the intermediates back to a Root CA Server, if you have multiple intermediate certificates!)
Here I have ONE intermediate, (which is pretty normal.)
There a no special tools you require to be able to do this, other than a simple text editor, you open your SSL certificate and ‘Paste” the intermediate certificate on the bottom. (DO NOT ADD ANY EXTRA SPACES). Like so;
Note: As you can see, you DON’T put the Root CA certificate at the bottom, (clients should already have them!) I made this mistake then got the following error;
[box]
Jun 23 14:12:29 localhost nginx[1197]: nginx: [emerg] PEM_read_bio_X509("/etc/nginx/ssl/www_petenetlive_com.crt") failed (SSL: error:0906D066:PEM routines:PEM_read_bio:bad end line)
Jun 23 14:12:29 localhost nginx[1197]: nginx: configuration file /etc/nginx/nginx.conf test failed
[/box]
Retry your test.
Related Articles, References, Credits, or External Links
This week I’ve been working on changing the site over to https. Buying a digital certificate used to be an expensive long winded affair, but not anymore. A quick internet search turned up a 3 year SSL certificate for less than 15 quid.
Getting the certificate was the easy bit, getting it installed so that Apache would use it was another ‘challenge’. On a scale of one to ten, I’m about a three (on a good day) with Linux!
Before you start, you need to generate a CSR and send that to whoever you are going to buy your cert from
What about free Certs? There are some firms that offer free certs, some require you to install software that updates the cert every ninety days, other have a short lifespan. I’m not usually one to spend any money but for a fiver a year, why not?
Solution
Your certificate vendor will sent you your certificate, it will probably come with at least one other cert. In my case it came with three other CA Certs (a RootCA and two Intermediate CA Certs). If you are unfamiliar with certificates, here’s the two golden certificate rules;
You MUST trust the authority (CA), that issued the certificate, or issued the cert to the CA that issued the cert etc.
The NAME on the certificate, either the Common Name (CN), or the Subject Alternative Name (SAN). MUST match the address you are going to.
What you will find with these <ahem> cheaper certificates, is that you trust a CA, and that CA issues another CA Certificate, (to a subordinate CA), that Issues another CA Certificate (To a Subordinate CA), and that CA issues your certificate. All these certificates form a ‘chain’ and it looks like this;
OK why is that important? Well to trust your certificate, your visitors, (and Apache) need to be able to see all the certificates in this chain, right back to the RootCA certificate at the top (which they will trust, or there’s not much point selling them!)
Some vendors will give you a certificate bundle, mine did not so I had to make one (this is not hard to do, see below). But now when you make that certificate bundle, you will have a better understanding of what you are doing, (putting all the CA certs in the chain order, into one file).
Installing SSL Certificates Into Apache
Before you start you may need to install mod_ssl ‘yum install mod_ssl’ will do that 🙂
First you need to copy all the files into CentOS, I created a folder in ‘/etc/ssl/’ called ‘localcertificates’ and copied in the domain cert, the key file (that got generated when I made the CSR – See the link above). And I’ve copied in all the CA Certificates. (I use FileZilla to do this because it’s free, and easy to use).
Now Log into your CentOS server via SSH and navigate to this directory, then use the ‘CAT’ command to make a certificate bundle with all your CA Certificates, (notice the order, SubCA2 > SubCA1 > RootCA). Note: Your certificates will probably have different names.
[box]
cd /etc/ssl/localcerts
cat COMODORSADomainValidationSecureServerCA.crtCOMODORSAAddTrustCA.crtAddTrustExternalCARoot.crt > My-CA.ca-bundle
[/box]
Now in the same directory you will have another file called My-CA.ca-bundle. To get Apache to use the certificates you need to edit the httpd.conf file. In CentOS 7 that usually lives in ‘/etc/httpd/conf’. I use nano because it’s easier to edit files with, (yum install nano). Im also going to back-up the config up as well, in case something goes wrong!
[box]
cd /etc/httpd/conf
cp httpd.conf httpd.conf-old
nano httpd.conf
[/box]
Locate the part of the file that says ‘Listen *.80’ and place a line below it that says ‘Listen *.443’.
Scroll to the end of the file and paste in the following, (change the filenames to match your own).
Note: Make Sure the Logs folder exists in /var/www if you use the same paths as me! Also SSLCertificateChainFile will change in newer versions of Apache to SSLCACertificatePath.
You can now restart Apache and browse to https://www.your-site.com. It can take a little while before it’s back up!
[box]
apachectl restart
apachectl status
[/box]
Everything’s Broken Help!!
This is why we backed up the config, first if there’s a problem ‘apache status’ usually says ‘theres a problem on line XYZ of the httpd.conf file’, if you open it in a text editor that will point you to a resolution. If all else fails, you can restore the original config like so;
[box]
cd /etc/httpd/conf
cp httpd.conf-old httpd.conf
apachectl start
apachectl status
[/box]
How To Redirect All HTTP Traffic to HTTPS in Apache?
That’s even easier, if you have a virtual host for poor 80 already setup in https.conf then just add ‘ Redirect / https://www.your-site.com/’ to it. I did not, but adding one did not break/affect my site at all. After the text you pasted in above for the virtualhost for SSL just paste in a new one for http (TCP port 80).
I was trying to enroll some ASA firewalls to NDES to get some certificates. Each time the process failed with the following error.
[box]
% Error in receiving Certificate Authority certificate: status = FAIL, cert length = 0[/box]
That’s a pretty generic error, and does not give me a lot to go on. So I thought I would try from another network device, (a Cisco Catalyst switch). It’s a little easier to ‘debug’ the process in IOS rather than on the ASA, so that’s what I did.
[box]
Enable NDES Debugging
Petes-Router# debug crypto pki messages
Crypto PKI Msg debugging is on
Petes-Router# debug crypto pki transactions
Crypto PKI Trans debugging is on
Petes-Router#
[/box]
The switch failed with the same error as the firewall but at least now I had some debugging information.
[box]
Petes-Router# show logg
Jan 4 10:31:11.818: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/21,
changed state to up
Jan 4 10:32:40.648: CRYPTO_PKI: pki request queued properly
Jan 4 10:32:40.648: CRYPTO_PKI: Sending CA Certificate Request:
GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=PNL-Trustpoint HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.1.100
Jan 4 10:32:40.648: CRYPTO_PKI: locked trustpoint PNL-Trustpoint, refcount is 1
Jan 4 10:32:40.656: CRYPTO_PKI: http connection opened
Jan 4 10:32:40.656: CRYPTO_PKI: Sending HTTP message
Jan 4 10:32:40.656: CRYPTO_PKI: Reply HTTP header:
HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.1.100
Jan 4 10:32:40.656: CRYPTO_PKI: unlocked trustpoint PNL-Trustpoint, refcount is 0
Jan 4 10:32:40.656: CRYPTO_PKI: locked trustpoint PNL-Trustpoint, refcount is 1
Jan 4 10:32:40.673: CRYPTO_PKI: unlocked trustpoint PNL-Trustpoint, refcount is 0
Jan 4 10:32:40.673: CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 200 OK
Content-Length: 7946
Content-Type: application/x-x509-ca-ra-cert
Server: Microsoft-IIS/8.5
Date: Wed, 07 Jan 2015 10:30:36 GMT
Connection: close
Content-Type indicates we have received CA and RA certificates.
Jan 4 10:32:40.673: CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=PNL-Trustpoint)
Jan 4 10:32:40.673: CRYPTO_PKI: status = 0x722(E_SIGNATURE_ALG_NOT_SUPPORTED :
signature algorithm not supported):crypto_certc_pkcs7_extract_certs_and_crls failed
Jan 4 10:32:40.673: CRYPTO_PKI: status = 0x722(E_SIGNATURE_ALG_NOT_SUPPORTED :
signature algorithm not supported): crypto_pkcs7_extract_ca_cert returned
Jan 4 10:32:40.673: CRYPTO_PKI: Unable to read CA/RA certificates.
Jan 4 10:32:40.673: %PKI-3-GETCARACERT: Failed to receive RA/CA certificates.
Jan 4 10:32:40.673: CRYPTO_PKI: transaction GetCACert completed
Petes-Router#
[/box]
So we are getting the CA cert and the RA cert from the NDES server but we can’t read them.
Here’s the slightly less descriptive debug from the ASA firewall.
[box]
Petes-ASA(config)# debug crypto ca transactions
Petes-ASA(config)# crypto ca authenticate PNL-Trustpoint
ERROR: receiving Certificate Authority certificate: status = FAIL, cert length = 0
Petes-ASA(config)# show loggcrypto_certc_pkcs7_extract_certs_and_crls failed (1826):
crypto_certc_pkcs7_extract_certs_and_crls failed
CRYPTO_PKI:crypto_pkcs7_extract_ca_cert returned 1826
Petes-ASA(config)#
[/box]
Solution
I really struggled with this one, the bottom line is the Cisco device can’t read the certificates, and the reason it can’t is actually shown above;
E_SIGNATURE_ALG_NOT_SUPPORTED
What this is telling us is that the signature algorithm that Windows Certificate Services is using can not be understood by the Cisco network devices. At first I thought It might be because I was using Windows Server 2012 R2, and it might have some new security feature.
So I built a test Server in VMware Workstation, and presented an ASA and router to it from GNS3 and it worked first time, (annoyingly). When I looked at the certificates and compared them, and took into account the debug above, I spotted the difference.
If the signature algorithm is set to sha1RSA, it works if it’s set to RSASSA-PSS it fails. To compound my problem even further I have a three tier PKI deployment with an offline root, intermediate (Sub CA), and an issuing CA (Sub CA). And the signature algorithm needs to be correct for EVERY CERTFICIATE IN THE CERTIFICATE PATH (CHAIN).
Why Has This Happened?
Basically when the offline root was created, I followed the instructions for deploying an offline CA as per the instructions on Technet. Before you even install the role, Microsoft recommend you create a CApolicy.inf file with the following line in it;
[box]AlternateSignatureAlgorithm=1[/box]
I says that this signature algorithm is more secure, but it’s not compatible with Windows XP. What IT DOES NOT SAY, is it’s incompatible with Cisco devices wanting to get certificates from NDES!
Note: Executing the following command also enables this;
From this point forward, all new certificates issued by this CA will use the older signature algorithm. So if you renew the CA Certificate the new one will be fine.
WARNING: When renewing the CA Cert MAKE SURE YOU DO NOT generate new keys (or previously issued certificates may stop working!)
If you only have one certificate server you can then simply remove NDES.
When NDES is reinstalled the new RA certs will use the correct signature algorithm.
What If You Have a Two or Three Tier PKI Deployment
If like me you have a multi tiered PKI deployment, you need to go all the way back to the Root CA > Fix that > Reissue all the Sub CA certs down the certificate path fixing each tier as you go.
Here’s the process I used, (Use at you own risk and I accept no responsibility if you trash your PKI environment).
Related Articles, References, Credits, or External Links