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.
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
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
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 ...
Just wanted to give a quick shout out to PaTmaN93 for investigating and posting these full set of instructions. I followed them, adjusting some things slightly as I did everything from a Windows workstation. It took me a few tries, and at one point I even locked myself out of a UTM (had to restore from backup), but eventually I got it to work. I verified that the change even works through a restart. Excellent work PaTmaN93! It's people like you that make forums work as well as they do.
One piece of advice...always have a backup of your UTM before making changes! Luckily I'm studious about this, and was able to restore the UTM I locked myself out of. Sure I could have always rebuilt it from scratch. But why?
-------------------------------
Interesting [in-ter-uh-sting, -truh-sting, -tuh-res-ting]
A word typically used by IT technicians to describe an issue they didn't expect, or never encountered, and don't know how to fix.
Did you follow the instructions from Patman93? When you connect to the UTM console, and list the certificate properties, it should look as if 2 certificates have been concatenated into a single certificate.
-------------------------------
Interesting [in-ter-uh-sting, -truh-sting, -tuh-res-ting]
A word typically used by IT technicians to describe an issue they didn't expect, or never encountered, and don't know how to fix.
Hi candal02, I would totally do that, but we are using a UTM9, which warranty would be voided as soon as I do changes as root from shell.
I can't be the only one having that issue on a SophoS box, not being able to change that because of warranty?
Ah yes. Although I haven't confirmed with Sophos myself, I don't believe that making changes to your certificate as root through the SSH console would void your warranty. That's the only change this solution has you doing through the shell. You aren't changing any other files. But you make a very good point. I recommend you open a ticket with Sophos support, tell them exactly what you want to do, and ask them to officially confirm or deny if doing it would void your warranty.
You definitely are NOT the only one having this issue. But so far this solution is the only one I have discovered that works. It would indeed be very disappointing if this voids your warranty. If you do find out the answer, would you mind posting it?
-------------------------------
Interesting [in-ter-uh-sting, -truh-sting, -tuh-res-ting]
A word typically used by IT technicians to describe an issue they didn't expect, or never encountered, and don't know how to fix.