No Luck Using a SSL Certificate with WebAdmin/User Portal

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@<utm>:/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 \n string:

$ sed ':a;N;$!ba;s/\n/\\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):

<.........\n-----END CERTIFICATE-----"

Add a \n to the end:

<.........\n-----END CERTIFICATE-----\n"

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 ...

Am I right if I say that this issue still isn' t fixed?

It is great that there are workarounds like for example provided by PatMaN93, but I prefer to not login into the terminal (I don't want to mess with Sophos or do things that you shoudn't be doing).
For that reason, I'm asking, after seeying so many topics on the Sophos comunnity, is it still not fixed?

Because I'm sorry but I'm not going to mess in the terminal, although I really do want my certificate to work.

And this is a real old problem, witch, in my honest opinion, should be fixed by now - right??

Okay then, that is unfortunate.

Well, I hope they fix it soon!!

Thank you

This thread goes back 3 years and there are other posts about this same issue from 5 years ago.  Looks to me like they have no intention of ever fixing it.  

Too bad...

Aren't there many other users having this problem? - I gues not

How do other people use they own certificates then?? - I gues they don't...

I think the point is, while it is a shortcoming of the product, it is just not that hard (in many cases) to concatenate the certs together to create a cert with the full chain and import that into Sophos.  I have seen some have a lot of issues with it, and I have no idea what causes it.  However, using a free certificate (startcom IIRC) I had to do this and it was pretty straightforward at the time.  I've since switched (6 months or so) to Let's Encrypt certs and it is also working fine, no concatenation needed.  So, YMMV.

The problem is concatenating them together and using the web interface to import them doesn't work.  In many cases the intermediate cert is already on the client system so it's not a problem.

darrellr said:

... it is just not that hard (in many cases) to concatenate the certs together to create a cert with the full chain and import that into Sophos. ...

Yeah, so I did this, but it did't work. Although Sonos did import all of the certificates.

I also had Let's Encrypt, but same there. YMMV indeed.

Too bad you can only fix this by loggin into the terminal as root and edit some files.

Just for now I use a PC, so the certificate is working. Only on Android (and other mobiles) I have the problem.

Luckely I also have a free Cloudflare account, so Cloudflares provides a certificate that is working ;-)
(and since Cloudflare dous recognise the certificate, it is truely safe)

Importing did work for me.

It imported the certificate and all 3 CA certificates.

Unfortunatly the Sonos Webinterface is only handing out one certificate to the clients, accordingly to Sonos staff the problem is in there. Sonos should give the certificate with root chain, but it dousn't. (as you can see if you look at the proposed fix in one of the many threaths)

I did not have to do anything special to get LetsEncrypt work.  With the startcom cert, firefox complained about the missing cert, but IE and Chrome filled in the gap in the background just fine.  You do have to be careful with concatenating and I had to use a linux console to get it done properly.  I could not make Windows work, nor could I copy/paste.  But it really wasn't difficult.  Maybe I just got lucky.

Okay.

Copy an paste worked for me.

Besides that, I just used OpenSSL on Windows, works like a charm.

This is a fascinating fragment from the Support statement:

     ...in the event intermediate certificates are used

Apparently they don't realize that every commercial certificate issued in the last 10 years (give or take) has required an intermediate certificate.

Very frustrated that they find a valid certificate chain so unimportant, for both WAF and User Portal/WebAdmin.

This is a fundamental security issue.   If you don't know who is on the other end of your conversation it does not matter that no one can eavesdrop on it!   This is why PCI requires that you NEVER connect to a site with an invalid certificate chain.  (PCI DSS v3.2 item 4.1)

This is a fascinating fragment from the Support statement:

     ...in the event intermediate certificates are used

Apparently they don't realize that every commercial certificate issued in the last 10 years (give or take) has required an intermediate certificate.

Very frustrated that they find a valid certificate chain so unimportant, for both WAF and User Portal/WebAdmin.

This is a fundamental security issue.   If you don't know who is on the other end of your conversation it does not matter that no one can eavesdrop on it!   This is why PCI requires that you NEVER connect to a site with an invalid certificate chain.  (PCI DSS v3.2 item 4.1)

The only time that I can think of that you would not have intermediate certs is if you were creating self signed certs.  Below was my reply to them.  As for PCI, we went with tokenization and P2PE.  Took a long time but it's worth it just to avoid that questionnaire.

From: Robert Yount
Sent: Friday, January 27, 2017 4:53 PM
To: Sophos Support
Subject: RE: [#6572145] SSL VPN issue

Thanks for the info, unfortunately everyone uses intermediate certificates. Seems like you need to have a KB article on this issue because there’s been quite a few discussions about this in the past. Don’t think there’s anything more that I need since it’s just the way it is until it gets fixed.

Thank you for the information Robert Yount.  I agree with DouglasFoster and others who have posted that Sophos really does need to understand the scope of this problem, and do something about it.  It's unfortunate that in this particular use case, you cannot implement certificates on a UTM in the way that certificates were designed to be used.  At least not without resorting to some method of workaround.  One of which may void your warranty.  I'm a huge proponent of Sophos, and love their functionality and ease of use.  And I will continue to use their products.  But in my humble opinion, this issue at the very least means a major lack in functionality of the product, which among other things, can lead to being unable to follow security and compliance regulations.  In the worst case, it introduces a gap in security.

On the upside, I do have blessing from Sophos Level 2 support to implement the CC commands which solve the WebAdmin/UserPortal certificate problem, so the warranty concern is probably unimportant.   (Although I have not implemented the change yet)  

No workaround yet to the problem that WAF sites send a root certificate as part of their certificate chain.

With firmware version 9.7, Sophos UTM finally supports uploading a public cert through webadmin that does NOT strip the intermediate certificate.  I have tested this on one of my devices, and can confirm it worked.  Man was that easier than going through a putty session.