No Luck Using a SSL Certificate with WebAdmin/User Portal

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

Matthew said:

 

JW0914

It's generally best to read the last page/last 10 posts on a thread prior to posting.  Please see the last reply prior to your post  

 

You are assuming (incorrectly) that I have not. I have seen your post about the solution, but found it difficult to parse. Perhaps you could rephrase. Pretend I am 5.

 

The Intermediate CA and CA certificate must be concatenated into a single pem.  This is done easiest on a Linux/BSD distro, as both will display the two certificates in hierarchy when the concatenated pem is opened (utilize the cat command in my previous post to do so [concatenate]).

Windows [cmd, not ps, terminal]: type '.\ICA.crt.pem' '.\CA.crt.pem' > '.\ICA-CA-Chain.crt.pem'

While Windows won't display the concatenated cert correctly, you can still verify it with: openssl x509 -in ICA-CA-Chain.crt.pem -text -noout

*nix/BSD: cat './ICA.crt.pem' './CA.crt.pem' > './ICA-CA-Chain.crt.pem'

Once you've done the above, the concatenated CA needs to be uploaded to WebGUI, as well as installed on any devices accessing the WebGUI/User Portal.  If either the CA or the Intermediate CA is not signed by a central public CA, Android will throw a warning toast upon every boot.  This can be easily removed if the device is rooted, as the certificate needs to be moved from userland to system trusted (takes only ~3 min to accomplish).

Thank you for taking the time to repost! I believe I have followed your instructions, but am still unable to clear the intermediate certificate warnings.

To recount, my GeoTrust RapidSSL is installed on the UTM.

I obtained the recommended intermediate certificate bundle from https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO28836, which I understand is the required concatenation of intermediate CA and root CA. I saved this as a .pem file (I am on Windows), then uploaded it from the web GUI.

Retested at https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp.

Still tells me the intermediate cert is missing. Could I have missed any steps?

Thanks, in advance.

I have the exact same symptom, and I have tried the suggested answer involving concatenating the two files into a single one.  I have tried re-generating the PKCS#12 file, I've tried uploading the concatenated CA (intermediate cert first) into the Certificate Authority tab, and just about every combo I can think of when generating the PKCS#12 file.  I can't get it to send the intermediate certificate out.

I'm currently using certs from StartSSL and I have this same symptom on two different UTMs with two different domains and certs.  Both are software UTMs but I don't think that plays a factor, does it?

What certificates are you including in the p12?  

• It should contain the following three files:  the concatenated ICA & CA [CA-Chain.crt.pem], the webadmin cert [webadmin.crt.pem], and the webadmin key [webadmin.key].

What do you mean by "...I have tried re-generating the PKCS#12 file, uploading the concatenated CA nto the Certificate Authority tab, and just about every combo I can think of when generating the PKCS#12 file. " &  "...I can't get it to send the intermediate certificate out."? 

• Sophos cannot utilize ICAs to issue certs.  I don't know why, however my guess is it has to do with security issues. 

• I believe an ICA signed WebAdmin cert can be utilized, but I'm not 100%.

Have you tried simply issuing the openssl command manually to create a p12?

• openssl pkcs12 -export -out '.\WebAdmin.p12' -inkey '.\WebAdmin.key.pem' -in '.\WebAdmin.crt.pem' -certfile '.\Sophos VPN 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 

• The OpenSSL utility can be downloaded for Windows or Linux/BSD.  If you need a preconfigured openssl.cnf, one can be found on my GitHub with all commands required at the bottom of the file, starting at line 546

Thanks for the reply.

Your suggested process to issue the pkcs12 is exactly what I have attempted in every way.  

• - The file listing you mention is exactly what I have used.  
• - The openssl command you listed is exactly what I have been using to create PKCS12 files.  
• - I have also attempted adding an additional -certfile command with each pem listed individually rather than in a concatenated file.  No change.  I've tried every combo I can think of with the same result in Firefox.
• - I've also tried downloading the CA and ICA files directly from Start SSL's site rather than using the bundled ones provided when the certs were issued to me.

At this stage, my belief is that the Sophos SG UTM does not send intermediate files to the client.  This is based on my results from multiple SSL test sites who state the intermediate or root certificate is not being sent with the response.

At this time, I do not know of an additional troubleshooting item I can attempt.

To clarify, please state exactly what you're trying to accomplish, because if it's the same as MatthewArciniega1, its user error.

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.

If this is the correct assumption:

1. Root CA and ICA need to be installed into each PC that will be accessing the WebAdmin and/or User Portals. 
   • [Sophos]
     • The Root CA and ICA will need to concatenated into a single pem and uploaded into Sophos via WebServer Protection -> Certificate Management -> Certificate Authority [Type: Verification CA].
   • 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
2. The Webadmin and User Portal cert are one and the same since they cover the domain name/public IP (if accessible from WAN) or host name/local IP (if LAN)
   • This cert (and it's key) does not get installed into any machine except the one running Sophos.  
   • [Sophos]
     • It should be uploaded into Sophos via WebAdmin, in the PKCS format, via WebServer Protection -> Certificate Management -> Certificates [New Certificate -> Method: Upload -> File Type: PKCS12]
       • The PKCS12 you generated with the WebAdmin cert, WebAdmin key, and concatenated ICA & CA pem as the signing authority
     • You will then need to set it as the WebAdmin cert via Management -> WebAdmin Settings -> HTTPS Certificate -> Choose WebAdmin/User Portal Certificate

I recommend verifying the PKCS12 and concatenated ICA & CA via openssl to ensure they have been correctly formatted, as if you're still receiving a chain of trust error, there's something wrong with how the concatenated PEM is formatted, or the proper CA(s) and ICA(s) have not been imported into the certificate store(s)

• Windows does not recognize a concatenated PEM as containing two certs and will only recognize the first cert listed in the text view of the cert.
  • In WIndows, the CA and ICA must be imported separately.  This may be the reason why you're having issues if the client machines are Windows, and if this is the case, simply importing the Root CA should solve this issue. 

I've attached a screenshot of what a concatenated ICA & CA should show for chain of trust (far left), and an accompanying client cert signed by the ICA (right).  

• If using Linux/BSD, the PEM will display two separate certificates when opened.
• If using Windows, you will need to import the Root CA first, prior to opening the ICA to view the cert.

If using Windows, you can have it recognize and display PEMs by saving the following to a .key file and importing into the registry (change registry version if yours isn't 5):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.pem]
@="CERFile"
"Content Type"="application/x-x509-ca-cert"

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.

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.

Well I had a large posting with details but the forum filters decided it was spam.  So here's the short version.

After uploading the p12 bundle it looks like the files are stored here:

/var/sec/chroot-httpd/etc/httpd/WebAdminCert.pem
/var/sec/chroot-httpd/etc/httpd/WebAdminKey.pem
/var/sec/chroot-httpd/etc/httpd/WebAdminCertCA.pem

The top file only contains the site cert, no 3rd party CA info.  The file looks like output from this command:

openssl x509 -in certificate.crt -text -noout

The second one is the private key for the site cert.

The third file is a locally generated cert which contains info found in Management, System settings.

There's also a configuration file that references the files above.

SSLCertificateFile /etc/httpd/WebAdminCert.pem
SSLCertificateKeyFile /etc/httpd/WebAdminKey.pem

So if it's using WebAdminCert.pem it's never going to work because the 3rd party CA info is not in the file.

Pretty much what this post says:

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

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!

This works great, however it seems that certificates are reset when the machine/VM is restarted. Might be a pain for those who restart occasionally.

Darn.  You are right.  I hadn't done a restart.  Must be getting copied back over from somewhere.

Robert