No Luck Using a SSL Certificate with WebAdmin/User Portal

Thank you for the very detailed response.  I'll try to be just as detailed in my reply.  I tried everything you showed and I'm no further ahead, I'm afraid.

Here is the exact command I am running to test and create my PKCS12 file:

openssl pkcs12 -export -out certificate.pfx -inkey private.key -in cert.crt -certfile chain.pem -chain

The chain.pem file is a concatenated file of the intermediate certificate and the root certificate, in that order.  This resulted in the following:

Error unable to get local issuer certificate getting chain.

When NOT using the -chain tag, the PKS file is created normally.  I upload that to the UTM into the >Webserver Protection > Certificate Management > Certificates

I have also uploaded the concatenated intermediate Class 1 certificate and the Root Certificate for StartSSL (from https://www.startssl.com/root ) to >Webserver Protection > Certificate Management > Certificate Authority as a "Verification CA".  Of particular interest, when I check where this is in use (using the {i} in the webadmin interface), it shows as in use by the certificate I uploaded in the previous paragraph.

I have tried creating the PKCS12 file with just the root, just the intermediate, the intermediate+root (concatenated), and root+intermediate (concatenated) with no luck.  Same chain error.

I still get firefox errors with no errors on Safari or Chrome.

What am I doing wrong?

Your PKCS12 command is incorrect and shouldn't contain the -chain flag in this situation.  I can't remember what situation it is required in, but it shouldn't be used when including a concatenated ICA-CA-chain.pem

What are the exact error(s) you're receiving in firefox?  Browsers will throw certificate errors for a variety of reasons, and if you're not getting errors with Chrome or Safari, then it's likely not a critical error; however, if you post the error message, I can do some research and get back to you.  My hunch is because it was issued from a signing authority still using the inadequate sha1 signing algorithm.

Just to verify, everything is working fine, with the exception of the firefox error?  I ask because I wasn't sure if the "...same chain error" was in reference to the FireFox issue or not.  If it's not, something is missing from the equation and you're going to need to use the OpenSSL verify commands to verify the modulus of each cert to it's issuing authority.  You're doing everything correctly, so I'm wondering if there isn't a second ICA involved that signed the ICA your cert is signed by.

Before squinting to compare moduluses, please list what the GUI chain of trust shows for the following certs [i.e. Certification Path in Windows]:

WebAdmin

ICA that signed WebAdmin

CA that signed ICA

Having the same issue here.  

This is what I used in OpenSSL.

openssl pkcs12 -export -out cert.pfx -inkey privatekey.key -in cert.crt -certfile intcacert.crt

I just don't believe the UTM is sending the intermediate CA.  I have a case open with support.  This issue has come numerous times.  In fact this thread goes back to Dec, 2013.  Something is wrong with the implementation in the UTM.

I'm not sure what you mean by "...I just don't believe the UTM is sending the intermediate CA."

• A router will never send an ICA or CA... those are used to authenticate the applicable certificates' validity that are negotiating the encryption of the encrypted traffic being sent and received.

The cert file needs to be a concatenated pem file as I've repeatedly stated throughout this thread, and I've also repeatedly addressed the above as well.  Please read back through my prior posts...

 A general FYI: Because I'm likely to respond with snark at this point, any other replies to this thread indicating a user did not read at least the last 10 posts, as well as other posts referenced, will not receive a reply and will be ignored.  I understand threads can span many pages, so asking one to briefly skim the last 10 posts, is not, I believe, asking too much.

See here, here, here, and here.

Perhaps if the whole thing was explained in one KB this would be easier to understand.  It's ridiculous to have to dig through a bunch of postings to figure this out.  The UTM should just handle the CSR generation and all the baggage that goes along with it to begin with.  Having to bring in a cert from Windows or OpenSSL shouldn't be necessary.

In your post here:

https://community.sophos.com/products/unified-threat-management/f/general-discussion/22147/no-luck-using-a-ssl-certificate-with-webadmin-user-portal/302338#302338

You state:

What I've assumed you've been trying to do is install a 3rd party signed WebAdmin cert into Sophos and have it so that you're not getting browser errors when navigating to the WebAdmin or User Profile pages.

Clients:

• [Windows]
  • Root CA will be imported into the Trusted Root Certification Authorites within Certificate Manager
• • ICA will be imported into the the Intermediate Certification Authorities within Certificate Manager

This is exactly what I am complaining about.  If the OS/Browser already trusts the CA why does it manually need to be installed in Windows?  That should only be necessary if you are using a self-signed cert.

What do you believe makes a browser trust a certificate, as it's not the browser...

Every OS comes pre-installed with root and intermediate CA certificates from the popular and trusted root and intermediate CAs (using self-signed CAs has nothing to do with it)... if an OS does not register a client/server cert as trusted, then one or two things are the cause of this (or both): either the root CA that signed the cert is not trusted in the certificate store [i.e. it hasn't been installed, or has been marked as not trusted], or the intermediate CA(s) is not in the certificate store.

• There can be multiple ICAs in a chain of trust, however the most I've seen commercially is two, with a chain of trust being: CA -> ICA1 -> ICA2 -> Client Certificate.
  • Client Certificate was signed by ICA2; ICA2 was signed by ICA1; ICA1 was signed by the root CA.
  • In this type of scenario, the root CA, ICA1, and ICA2 would need to be installed into the certificate store for chain of trust to be maintained.  The CA would go under root CAs, the two ICAs would go under the Intermediate CA category. The CA cert would likely be a concatenation of ICA2, ICA1, CA.

This is not an issue with Sophos, but a fundamental misunderstanding of certificate chain of trust.

"If the OS/Browser already trusts the CA why does it manually need to be installed in Windows"

Obviously the OS does not have a chain of trust for the certificate, else you wouldn't be having a chain of trust issue.  If you believe you do have a proper chain of trust, please do what I asked the other user to do here (bottom of post).

In Apache server and other HTTP servers, you can set the "CA Cert" OR you can concatenate the site cert with the hostname, the intermediate cert and signing CA. In the case of Comodo there are two intermediate certs: COMODO RSA Domain Validation and COMODO RSA Certification Authority. So you could concatenate the website hostname certificate, Comodo RSA Domain Validation and Comodo RSA CA into a single pem and set that in Apache as the "website certificate", then of course set the key file. What this causes Apache to do is that it provides the entire chained PEM file during the SSL handshakes, which provides the web client's browser the necessary intermediate certs to complete the chain of trust.

What appears to be wrong with the UTM is that even if the intermediates are all part of a single PEM, it is only sending the "site hostname" or "WebAdmin" cert, it's ignoring the intermediates entirely even if they are all concatenated. For example:

• cat sophos.domain.com.crt comodo-domain-validation.pem comodo-rsa-cert.pem >> sophos.domain.com-chain.pem
• openssl pkcs12 -export -out sophos.domain.com.net-chain.pfx -inkey sophos.domain.com.key -in sophos.domain.com-chain.pem -name "sophos.domain.com"

Uploaded the pfx file to the UTM and I set the WebAdmin to use that cert. Upon browsing to the WebAdmin, Chrome still shows a certificate CA validation error. Following the same procedure but uploading to an Apache server, everything works 100%. The issue does appear to be a problem with the UTM not sending all of the certs in the chain as part of the SSL handshake.

Perhaps I'm missing something, but where is the root CA in all of this?

• If ICA comodo-domain-validation.pem was signed by ICA comodo-rsa-cert.pem, where is the root CA that signed comodo-rsa-cert.pem?
  • This is the most likely cause of the error, as there's no chain of trust without the root CA that signed comodo-rsa-cert.pem

What does openssl say when you verify the moduluses of sophos.domain.com-chain.pem and sophos.domain.com.net-chain.pfx?

• openssl x509 -text -noout -in ./sophos.domain.com-chain.pem
• openssl pkcs12 -info -in ./sophos.domain.com.net-chain.pfx

 ...Following the same procedure but uploading to an Apache server, everything works 100%...

• I'm assuming this to mean you navigated to the Apache webserver's SSL webpage and there were no certificate errors in Chrome?
  • If this is the case, it's likely the system that web server is running on has the missing root CA installed as a part of it's CAcerts bundle

What is the exact error message Chrome is showing?  

• There is a known issue with Chrome and PolarSSL on Chrome v51+, however UTM uses OpenSSL
  • Chrome [v51+] requires AES-GCM and CAMELLIA-GCM ciphersuites to successfully handshake with a server using the ustream-polarssl backend.
    • If CONFIG_GCM is disabled, ssl_ciphersuite_from_id() will return NULL when cipher 0x9d is looked up ^{(TLS_RSA_WITH_AES_256_GCM_SHA384)}
    • This results with the call ssl_ciphersuite_match() to fail with POLARSSL_ERR_SSL_INTERNAL_ERROR ^{(RFC 5288)}

Does IE, FireFox, or any other browser throw an error (installed on same system as Chrome)?

• If they do, the problem is with the chain of trust and not browser related

What occurs in Apache if you specify the CA cert instead of concatenating it within the domain cert?

• What occurs if you create a p12 with the domain cert, domain key, and concatenated ICA-ICA-CA chain as the certfile?
  • If one is already utilizing a p12 for the web server, why not utilize the general form of providing chain of trust via the above bullet?
  • openssl pkcs12 -export -out ./sophos.domain.com.net-chain.p12 -inkey ./sophos.domain.com.key -in ./sophos.domain.com.crt -certfile ./ICA-ICA-CA_Chain.pem
    • Verify: openssl pkcs12 -info -in ./sophos.domain.com.net-chain.p12
    • Where ICA-ICA-CA_Chain.pem is:
      • cat ./comodo-domain-validation.pem ./comodo-rsa-cert.pem ./missing-root-CA.pem > ./ICA-ICA-CA_Chain.pem
        • Append [ >> ] shouldn't be used, as it allows for a mistake to be made (such as appending to an existing file)
        • Verify: openssl x509 -text -noout -in ./ICA-ICA-CA_Chain.pem

Also, does Sophos use Apache as it's webserver?  

• I can't check since my UTM is offlined at the moment due to issues within the last two updates resulting in the WAN uplink being wholly unreliable, plagued by repeated disconnects caused by something unknown within the last two updates.
  

The simple solution to all of this is installing the ICA and CA certs onto the client PCs; however, if one wishes to determine the cause, all the above will need to be sorted out.  The problem is most likely user error and not following the proper etiquette of providing certificate chain of trust, which would be the case since the root CA is nowhere to be found.

• While .pfx [Microsoft] can still be utilized, it's been depreciated for a while now, with .p12 [RSA Laboratories] superseding it

There's no reason to install the root and intermediate certs onto the clients.  If I go to that trouble I might as just use self-signed certs.  The root should already be on the client anyway.  And in reality the root shouldn't be necessary on the UTM either.

From RFC 5246 - certificate_list
This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

We also have an OpenVPN server running under Ubuntu.  I have had to replace the cert twice and have never had any trouble like this.  You are correct that pfx has been deprecated.  It's not correct, but the extensions are used somewhat interchangeably like saying SSL instead of TLS.  

I went ahead and spent $9 on a cheap cert tonight.  If I get a chance I'll try this all over again tomorrow on a different UTM.

Where do you believe root ca's are installed from?  The ether?  Perhaps they simply pop into existence in a puff of smoke on a PC?  From the information you've provided, your issue appears to be there's no certificate chain of trust back to the root CA that signed the 1st ICA.  What root CA signed that ICA?  Once you verify what CA it is, you'll then need to verify if that CA is installed on the client [under Trusted Root CAs] and Sophos [verification CA]... most likely, it's not (in the filesystem, it's saved as /var/chroot-httpd/etc/httpd/WebAdminCertCA.pem)

• I've been assuming you've read through the thread, as you should also have uploaded a complete chain PEM containing ICA2 -> ICA1 -> Root CA to the UTM as a verification CA

I'm well aware of the sequence of certs in a certificate chain... the chain would need to be configured in the way I listed.  I've spent hours writing and formatting posts on this thread, providing exactly how to do what one needs to do to maintain chian of trust; since I'm to the point of becoming snarky, best of luck to you.  

I encourage you to re-read what I wrote, specifically about verifying your certs, which you still haven't bothered to do.  Hopefully someone else takes pity, as I'll no longer reply to thread... the information you require has been given to you, it's your choice whether or not you're going to use it.  Cheers =]

 Oh and one other thing... the only difference between a commercial CA and a Self-Signed CA is the trust factor in the CRL.  When one purchases a certificate, one isn't paying for the certificate, one is paying for the management of the CRL and the layer of trust that results in.  Unless one has a website that will see random traffic (i.e. not the same pool of users), or processes financial information, there's nothing gained by going with a commercial CA.  In fact, more often than not, my Self-Signed CA & ICAs are more secure than many commercial CAs & ICAs... but again, what one is paying for is the CRL management.