No Luck Using a SSL Certificate with WebAdmin/User Portal

Question

Short Version:  ———————— I am unable to successfully install a publicly signed SSL certificate and along with it’s intermediate certificate for use in WebAdmin and the User Portal.   After installation only some browsers (Safari & Chrome on OS X) show it as trusted. Others (Firefox on OS X, Safari on iOS, Chrome on Android, etc.) show it as untrusted.  Can anyone provide guidance?   Long Version:  ———————— Following the KB articles at: Create and Import a Public Signed Certificate for UTM Web Application Security  How to import and use your own certificate for WebAdmin in Astaro Security Gateway   I created a private key and corresponding CSR and submitted it for a UCC certificate with 20 SAN’s.  Using openssl I combined the resulting certificate and my private key in to a [FONT="Courier New"]p12[/FONT] file. I uploaded it to the UTM (Remote Access > Certificate Management > Certificate > + New certificate), along with the Intermediate certificate previously converted from a crt to pem using openssl (Remote Access > Certificate Management > Certificate > Certificate Authority).   I then selected the cert (Managment > WebAdmin Settings HTTPS Certificate > Choose WebAdmin/User Portal Certificate).  When testing across browsers Safari and Chrome show the certificate as trusted/verified. However, iOS, Android, Firefox, etc. do not.  When verifying via openssl with the command:  [FONT="Courier New"]openssl s_client -showcerts -connect mywebadmin.mydomain.com.au:443[/FONT]  I get the error:  [FONT="Courier New"]Verify return code: 21 (unable to verify the first certificate)[/FONT]  Only the primary domain certificate is listed; not the intermediate or the root, so there appears to be no chain of trust. It would appear that most likely the browsers that work are assembling the chain of trust from their own keystones???  Using the exact same [FONT="Courier New"]p12[/FONT] on other servers works perfectly fine. Browsers accept and openssl (which I am assuming does not have a keystore) verify it as fine displaying the full chain of trust. I have tried adding the complete trust chain (primary domain + intermediate CA + root CA) to the certificate to no avail. From what I can tell the intermediate CA is not being presented to clients, only the primary. But I'm a noob when it comes to SSL.  Any suggestions on fixing?

PaTmaN93 · Accepted Answer

Okay, so after playing with this for far longer than we should have to, we've come up with a solution that will survive reboots :) First of all, we need to generate the correct certificate file including the entire chain of intermediate certificates except for the root certificate. The structure will be similar to this: ... there might be some metadata in here, or not ... -----BEGIN CERTIFICATE----- end-entity certificate, the one given to you by your CA -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- --| -----END CERTIFICATE----- | certificate chain between your end-entity ... |-- cert and the root certificate, -----BEGIN CERTIFICATE----- | excluding both -----END CERTIFICATE----- --| To make this simpler and more consistent, i’ll work through an example with a certificate for webmail.example.com . Substitute this for your own domain wherever applicable. Getting the correct intermediate chain You can get the correct chain from checking your site on https://whatsmychaincert.com : Under “Test Your Server”, enter your UTM’s public hostname and press Test. Most likely, you’ll get an error: Click the This link to download the correct certificate chain (the website explains how this works, if you’re curious). I’ll save it as webmail.example.com.chain.crt . Now, concatenate your end-entity certificate with the certificate chain. If you don’t know where to find your end-entity certificate, you can get it off your UTM appliance like so: $ scp loginuser@:/var/confd/certs/host.cert host.crt To create the correct certificate chain: $ cat host.crt webmail.example.com.chain.crt > webmail.example.com.crt Prepare certificate This step will make sense a little bit later. Basically we need to replace all 0a characters (line feed) in the webmail.example.com.crt file with the string: $ sed ':a;N;$!ba;s/ /\n/g' webmail.example.com.crt > webmail.example.com-prepared.crt Paste certificate into UTM’s confd storage Next, ssh into your UTM box: $ ssh loginuser@utm $ sudo su - root # cc Now you’re in the Confd-Client of the UTM appliance. To modify the certificate, we need to figure out its REF-id in the system. The easiest way I know of is to find a reference to it somewhere in the object tree. In my case, it was used under webadmin/cert$ : 127.0.0.1 MAIN > webadmin 127.0.0.1 MAIN webadmin > cert$ webmail.example.com [REF_CaHosWebmailexa] That REF_ string is the key to the certificate we want to modify. Yours will most likely be different. Now, re-enter the confd-client: 127.0.0.1 MAIN webadmin/cert (REF:ca->host_key_cert) > exit # cc Open the certificate object behind that REF_ key. For that we need to enter OBJS mode (replace REF_CaHosWebmailexa with the REF key): 127.0.0.1 MAIN > OBJS 127.0.0.1 OBJS > ca 127.0.0.1 OBJS ca > REF_CaHosWebmailexa Now for the tricky part. Enter certificate="" , but dont press [Enter] yet. 127.0.0.1 OBJS ca [REF_CaHosWebmailexa] > certificate="" Move the cursor in between the two quotes. Now, from the webmail.example.com-prepared.crt file we created earlier, copy the first line without the newline character at the end (i.e. everything from the beginning until, and including, the last dash of END CERTIFICATE----- ). Paste it into the terminal. The input line should look like this now ( dont press [Enter] yet): <......... -----END CERTIFICATE-----" Add a to the end: <......... -----END CERTIFICATE----- " Now press [Enter]. Check the certificate property of the object again: It should look exactly like the original webmail.example.com.crt certificate file opened in a text editor (except for the very first line). If it looks good, commit the change by entering w : (or abort with Ctrl+C if not) 127.0.0.1 OBJS ca [REF_CaHosWebmailexa] > w The certificate should immediately be applied and loaded into the web server. Check https://whatsmychaincert.com again: the certificate chain should now be correct and it will survive reboots as well \o/ Of course, if you ever change the certificate in the WebAdmin UI, you will have to do this again. The UTM software really should save the certificates in the configuration data this way by default, with all the intermediate certs attached, but for some reason it doesn't ...

Robert Yount · Answer

I offer this as a solution. Here's everything from the beginning. 
 
 Create CSR and private key in OpenSSL. 
 openssl req -out site.csr -new -newkey rsa:2048 -nodes -keyout private.key 
 Get your site certificate and CA certs from the CA. 
 
 Create PKCS12 in OpenSSL: 
 openssl pkcs12 -export -out site.p12 -inkey private.key -in sitecert.crt -certfile cachain.crt 
 sitecert.crt Your site certificate that came from the CA. 
 cachain.crt: I used the intermediate + root CA since the CA sent them together in a bundle. You may only need the intermediate CA but doesn't hurt to have both. (Or more if needed) 
 
 UTM > Remote Access, Cert Mgmt 
 New Certificate 
 Give it a name, upload, PKCS#12, browse to file, provide password for file, save. 
 You should see your site cert in Certificates and the CA certs in the Certificate Authority tab. 
 Activate your new cert in Management, WebAdmin settings, HTTPs Certificate. 
 Test it: https://www.digicert.com/help/ 
 The trust chain is most likely broken. 
 If so, combine the site cert, intermediate CA, and Root CA into a single file named WebAdminCert-fixed.pem. 
 -----BEGIN CERTIFICATE----- <domain_name crt> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate CA crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root CA crt) -----END CERTIFICATE----- 
 Turn on shell access in the UTM. 
 Upload the file to the UTM using WinSCP or another client. I chose to upload it to /tmp. 
 Use putty or another client to SSH into the UTM as loginuser. 
 su root 
 cd /var/sec/chroot-httpd/etc/httpd 
 cp WebAdminCert.pem WebAdminCert.pem.bak 
 cp /tmp/WebAdminCert-fixed.pem WebAdminCert.pem 
 /etc/init.d/httpd restart 
 Test at: https://www.digicert.com/help/ 
 Also make sure you can still login to the UTM Admin page before exiting the shell. 
 exit 
 exit 
 Turn off shell access. 
 Done!

lorenzenstefan · Answer

Hi, 
 Please use the shell to solve the problem. 
 Check the configuration in /var/sec/chroot-httpd/etc/httpd. 
 In WEB-Interface you can see, that the UTM uses the right certificate. But in the config file you see the different! UTM uses an different certificate! 
 In case of using intermediate certificates you have to edit the configuration in /var/sec/chroot-httpd/etc/httpd/vhost/httpd-portal.conf 
 SSLCertificateFile /etc/httpd/WebAdminCert.pem SSLCertificateKeyFile /etc/httpd/WebAdminKey.pem SSLCertificateChainFile /etc/httpd/intermediate1.pem SSLCACertificateFile /etc/httpd/intermediate2.pem 
 MfG Stefan

JW0914 · Answer

The issue is occurring due to improper certificate etiquette... Whenever an Intermediate CA is involved, the Intermediate CA and CA must be concatenated into a single PEM in order to maintain hierarchy. 
 
 cat "./IntermediateCA.crt.pem" "./CA.crt.pem" > "./Intermediate-CA-Chain.crt.pem" 
 
 The Intermediate CA is still used to sign the certs it issues; however, the CA - Intermediate CA chain cert must be exported with the client cert & key to maintain the certificate chain of trust of Certificate -> Intermediate CA -> CA. This allows for the certificate path of the client cert to show a hierarchy of CA -> Intermediate CA -> Client

Correct Layout 
 -----BEGIN CERTIFICATE----- 
 ### Intermediate CA ### 
 -----END CERTIFICATE----- 
 -----BEGIN CERTIFICATE----- 
 ### CA ### 
 -----END CERTIFICATE----- 
 Once concatenated, the Intermediate-CA-Chain.crt.pem must be used in lieu of the signing certificate when creating the p12. 
 Windows will not be able to show both certificates in the PEM in gui form (it will only show the first listed, the Intermediate CA), however, if opened in a *nix OS, it will display both certs in gui form 
 Please note, Intermediate CAs and Certs cannot be utilized for Sophos VPNs due to the way in which Sophos authenticates the certificates.

sachingurung · Answer

Hi, 
 "After installation, only some browsers (Safari & Chrome on OS X) show it as trusted. Others (Firefox on OS X, Safari on iOS, Chrome on Android, etc.) show it as untrusted." 
 If the configuration works on a set of browser and doesn't work on the other set then, it should be a problem more inclined towards the non-working set of browsers. 
 Alongside, there is known that the full certificate chain is not provided via UTM which effects functionalities like a PCI scan: reported under NUTM-4380. 
 Can you try to add the certificates from a different route and verify if that works, Web Protection>Filtering Options>Misc>Certificate for End-User Pages. 
 Restart httpproxy, /var/mdw/scripts/httpproxy restart 
 Any help with that? If the issue is not resolved through this I suggest you should contact Support. 
 Thanks

Robert Yount · Answer

It is not fixed. Below is the response I received from support on the case that I opened. 
 
 From: Sophos Support Sent: 2017-Jan-17 01:41 PM Based on what you are saying in your last message it sound like you are hitting a known issue where the UTM does not provide the full certificate chain for requests made to WebAdmin or User Portal in the event intermediate certificates are used. There is a workaround for this issue, which is what was mentioned in the community thread you linked. From the backend of the UTM we can append the WebAdmin CA and intermediate CA(s) in one pem file and copy it to /var/sec/chroot-httpd/etc/httpd/WebAdminCertCA.pem. The downside to this workaround is that it would need to be re-applied after each firmware upgrade. In the long run the general solution would be to implement a mechanism to handle intermediate certificates through the standard workflow although unfortunately I do not have any ETA on a formal solution. In the meantime though this workaround should get you up and running and is relatively easily applied after any upgrade of the UTM firmware.