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

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.

Could someone please do an ELI5 version? I'm not really sure what to do here.

I have a GeoTrust RapidSSL installed and used by my web portal. However, I have some mobile client browsers (Android 4.2, I believe) that are showing the certificate as untrusted. Furthermore, when I test the cert using a tool like https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp, it notifies me of a missing intermediate certificate.

I first tried uploading the intermediate cert as a PEM, to Certificate Authority. No change.

I then loaded the intermediate cert into a PEM file with my main cert, re-did the openSSL pks export, then re-installed that to my UTM. Both certs are listed (one under Certificates, the other under Certificate Authority). No joy. Test results are exactly as before.

If I SSH in, and look at WebAdminCertCA.pem, this is the original self-signed cert, not my freshly-uploaded intermediate cert.

Help me, Obi Wan...

Could someone please do an ELI5 version? I'm not really sure what to do here.

I have a GeoTrust RapidSSL installed and used by my web portal. However, I have some mobile client browsers (Android 4.2, I believe) that are showing the certificate as untrusted. Furthermore, when I test the cert using a tool like https://cryptoreport.rapidssl.com/checker/views/certCheck.jsp, it notifies me of a missing intermediate certificate.

I first tried uploading the intermediate cert as a PEM, to Certificate Authority. No change.

I then loaded the intermediate cert into a PEM file with my main cert, re-did the openSSL pks export, then re-installed that to my UTM. Both certs are listed (one under Certificates, the other under Certificate Authority). No joy. Test results are exactly as before.

If I SSH in, and look at WebAdminCertCA.pem, this is the original self-signed cert, not my freshly-uploaded intermediate cert.

Help me, Obi Wan...

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 

JW0914 said:

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.

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