Issues with custom certificate

[g4m3r7ag]

I can't seem to get this to work with a custom SSL cert. I created the self-signed cert using my CA in pfSense. That CA is trusted on my browser as I can access services using self-signed certs without an SSL error. I created the following directories

/docker-data/unms
/docker-data/unms/usercert

I downloaded the CRT and KEY files from pfSense and placed them in /docker-data/unms/usercert

These directories and files show ownership as administrator:administrator (my default user on this host). The files are named custom.crt and custom.key and have permissions equal to 664 (-rw-rw-r--)

Here is my compose file

version: '2'
services:
  unms:
    container_name: unms-controller
    image: nico640/docker-unms:latest
    restart: always
    ports:
      - 5080:80
      - 7443:443
      - 3055:2055/udp
    environment:
      - TZ=America/New_York
      - PUBLIC_HTTPS_PORT=7443
      - PUBLIC_WS_PORT=7443
      - SSL_CERT=custom.crt
      - SSL_CERT_KEY=custom.key
    volumes:
      - /docker-data/unms:/config

And the ls -l of the directories just for clarity

administrator@docker01:/docker-data$ ls -l
drwxrwxr-x  3 administrator administrator 4096 Nov 23 19:23 unms

administrator@docker01:/docker-data$ cd unms/

administrator@docker01:/docker-data/unms$ ls -l
total 8
-rw-rw-r-- 1 administrator administrator  402 Nov 23 19:12 docker-compose.yml
drwxrwxr-x 2 administrator administrator 4096 Nov 23 19:23 usercert

administrator@docker01:/docker-data/unms$ cd usercert/

administrator@docker01:/docker-data/unms/usercert$ ls -l
total 8
-rw-rw-r-- 1 administrator administrator 1631 Nov 23 19:23 custom.crt
-rw-rw-r-- 1 administrator administrator 1704 Nov 23 19:23 custom.key
administrator@docker01:/docker-data/unms/usercert$

After running the compose file the directory structure looks like this

administrator@docker01:/docker-data$ ls -l
drwxrwxr-x  9           911           911 4096 Nov 23 19:31 unms

administrator@docker01:/docker-data$ cd unms/

administrator@docker01:/docker-data/unms$ ls -l
total 32
drwxr-xr-x  2 administrator administrator 4096 Nov 23 19:32 cert
-rw-rw-r--  1 administrator administrator  402 Nov 23 19:12 docker-compose.yml
drwxr-xr-x  2 nobody        nogroup       4096 Nov 23 19:31 logs
drwx------ 19 messagebus    crontab       4096 Nov 23 19:32 postgres
drwxr-xr-x  2           911           911 4096 Nov 23 19:31 redis
drwxr-xr-x  3 root          root          4096 Nov 23 19:32 siridb
drwxr-xr-x  8 root          root          4096 Nov 23 19:32 unms
drwxrwxr-x  2 administrator administrator 4096 Nov 23 19:30 usercert

administrator@docker01:/docker-data/unms$ cd usercert/

administrator@docker01:/docker-data/unms/usercert$ ls -l
total 8
-rw-rw-r-- 1 administrator administrator 1631 Nov 23 19:23 custom.crt
-rw-rw-r-- 1 administrator administrator 1704 Nov 23 19:23 custom.key

administrator@docker01:/docker-data/unms/usercert$ cd ..

administrator@docker01:/docker-data/unms$ cd cert/

administrator@docker01:/docker-data/unms/cert$ ls -l
total 8
-rw-r--r-- 1 administrator administrator 1631 Nov 23 19:31 custom.crt
-rw------- 1 administrator administrator 1704 Nov 23 19:31 custom.key
lrwxrwxrwx 1 administrator nogroup         12 Nov 23 19:32 live.crt -> ./custom.crt
lrwxrwxrwx 1 administrator nogroup         12 Nov 23 19:32 live.key -> ./custom.key

So the UNMS directory changes to 911:911, the cert directory gets created as administrator:administrator, and the custom.key file gets copied into the cert directory and has permissions as 600.

The links in the this directory are administrator:nogroup

The logs show during startup

unms-controller | Enabling UNMS https and wss connections on port 443
unms-controller | Updating custom certificate.
unms-controller | mv: cannot create regular file '/cert/custom.key': Permission denied
unms-controller | Failed to copy key.
unms-controller | No certificate found.
unms-controller | Generating self-signed certificate for 'localhost'.
unms-controller | Waiting for rabbit@5a2a3efbb160 ...
unms-controller | pid is 428 ...
unms-controller |
unms-controller |               RabbitMQ 3.6.6. Copyright (C) 2007-2016 Pivotal Software, Inc.
unms-controller |   ##  ##      Licensed under the MPL.  See http://www.rabbitmq.com/
unms-controller |   ##  ##
unms-controller |   ##########  Logs: /var/log/rabbitmq/rabbit@5a2a3efbb160.log
unms-controller |   ######  ##        /var/log/rabbitmq/rabbit@5a2a3efbb160-sasl.log
unms-controller |   ##########
unms-controller |               Starting broker...
unms-controller | FATAL:  role "root" does not exist
unms-controller | /var/run/postgresql:5432 - accepting connections
unms-controller | FATAL:  role "root" does not exist
unms-controller | /var/run/postgresql:5432 - accepting connections
unms-controller | 1000
unms-controller | /usr/src/ucrm/scripts/init_log.sh
unms-controller | /usr/src/ucrm/scripts/dirs.sh
unms-controller | Failed to generate self-signed certificate for 'localhost'
unms-controller | 2020/11/23 19:31:11 [emerg] 913#913: open() "/etc/nginx/ip-whitelist.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/unms-https+wss.conf:36
unms-controller | nginx: [emerg] open() "/etc/nginx/ip-whitelist.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/unms-https+wss.conf:36
unms-controller | Starting nginx...

And trying to access the controller after that results in a privacy error "NET::ERR_CERT_INVALID" and when I click advanced there is no option to proceed anyway and it states

192.168.1.30 normally uses encryption to protect your information. When Google Chrome tried to connect to 192.168.1.30 this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be 192.168.1.30, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit 192.168.1.30 right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

The cert that was created has a common name of unms.ad.mydomain.com with an alternate name of 192.168.1.30. This is how I created my other certs and accessing them via fqdn or IP results in no SSL warnings.

If I attempt to connect via the fqdn I get the same thing

unms.ad.mydomain.com normally uses encryption to protect your information. When Google Chrome tried to connect to unms.ad.mydomain.com this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be unms.ad.mydomain.com, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit unms.ad.mydomain.com right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later.

I'm assuming it's some sort of permissions error with all the different ownership and permissions that are created when the container is first run but I am unsure. If I run the container without the custom SSL env variables it creates a localhost self signed cert and I am able to connect to the controller via IP (after clicking proceed anyway on the SSL warning) however after a couple of minutes the session seems to disconnect, there's a warning popup on the controller that the connection has been lost and if I refresh the page I am presented with the SSL warning again. Seems to happen ever 2-3 minutes.

[Nico640]

Sounds like unms is not the owner of cert/custom.key and therefore can't access it because of the 600 file permission.
Could you take a look at the /config/cert and /config/usercert directories from inside the container? (docker exec -it unms-controller /bin/bash)

They should look something like this:

ls -l /config/usercert/
-rw-rw-rw- 1 root root 1038 Nov 24 22:30 custom.crt
-rw-rw-rw- 1 root root 1679 Nov 24 22:30 custom.key

ls -l /config/cert
-rw-r--r-- 1 unms unms    1038 Nov 24 22:30 custom.crt
-rw------- 1 unms unms    1679 Nov 24 22:30 custom.key
lrwxrwxrwx 1 unms nogroup   12 Nov 24 22:31 live.crt -> ./custom.crt
lrwxrwxrwx 1 unms nogroup   12 Nov 24 22:31 live.key -> ./custom.key

[g4m3r7ag]

I’m out of town currently will try to look at this next week and report back.

…

On Tue, Nov 24, 2020 at 16:37 Nico640 ***@***.***> wrote: Sounds like unms is not the owner of cert/custom.key and therefore can't access it because of the 600 file permission. Could you take a look at the /config/cert and /config/usercert directories from inside the container? (docker exec -it unms-controller /bin/bash) They should look something like this: ls -l /config/usercert/ -rw-rw-rw- 1 root root 1038 Nov 24 22:30 custom.crt -rw-rw-rw- 1 root root 1679 Nov 24 22:30 custom.key ls -l /config/cert -rw-r--r-- 1 unms unms 1038 Nov 24 22:30 custom.crt -rw------- 1 unms unms 1679 Nov 24 22:30 custom.key lrwxrwxrwx 1 unms nogroup 12 Nov 24 22:31 live.crt -> ./custom.crt lrwxrwxrwx 1 unms nogroup 12 Nov 24 22:31 live.key -> ./custom.key — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALEIAFFORID2GMNQFKHQEMTSRQRQJANCNFSM4UAGTVKQ> .

[Artiik373]

@g4m3r7ag did you have the chance to get back in town yet

[g4m3r7ag]

To be honest I completely got side tracked. I should have time to mess with it tonight. I only have one site in UNMS so it’s easy to forget about. Apologies.

…

On Wed, Apr 14, 2021 at 15:30 Artiik373 ***@***.***> wrote: @g4m3r7ag <https://github.com/g4m3r7ag> did you have the chance to get back in town yet — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALEIAFDQN4ZFUQ2WQ22B4EDTIXUMDANCNFSM4UAGTVKQ> .

[g4m3r7ag]

I spun up a new container to test this. I created the usercert directory and placed my cert and key there before the initial run. Ran the container and it assigned the proper permissions to the file assuming the unms uid/gid would be 1001 as it's not showing me the name because those users don't exist on my host. However the cert doesn't seem to be loading properly as I still get a certificate error, but better then before as it at least is letting me bypass the error now. Maybe if there was a way to specify the UID/GID to run the services as?

administrator@docker01:/docker-data/unms$ ls -l
total 32
drwxr-xr-x  2   1001  1001 4096 Apr 15 00:46 cert
-rw-rw-r--  1 root   root   432 Apr 15 00:41 docker-compose.yml
drwxr-xr-x  2 nobody 65533 4096 Apr 15 00:45 logs
drwx------ 19     70    70 4096 Apr 15 01:06 postgres
drwxr-xr-x  2    911   911 4096 Apr 15 00:45 redis
drwxr-xr-x  4 root   root  4096 Apr 15 00:45 siridb
drwxr-xr-x  9   1001  1001 4096 Apr 15 00:46 unms
drwxrwxr-x  2 root   root  4096 Apr 15 00:42 usercert
administrator@docker01:/docker-data/unms$ cd usercert/
administrator@docker01:/docker-data/unms/usercert$ ls -l
total 8
-rw-rw-rw- 1 root root 1631 Apr 15 00:42 unms.ad.mydomain.com.crt
-rw-rw-rw- 1 root root 1704 Apr 15 00:42 unms.ad.mydomain.com.key
administrator@docker01:/docker-data/unms/usercert$ cd ..
administrator@docker01:/docker-data/unms$ cd cert/
administrator@docker01:/docker-data/unms/cert$ ls -l
total 8
-rw-r--r-- 1 1001  1001 1631 Apr 15 00:45 custom.crt
-rw------- 1 1001  1001 1704 Apr 15 00:45 custom.key
lrwxrwxrwx 1 1001 65533   12 Apr 15 00:46 live.crt -> ./custom.crt
lrwxrwxrwx 1 1001 65533   12 Apr 15 00:46 live.key -> ./custom.key
administrator@docker01:/docker-data/unms/cert$ 

Compose file

administrator@docker01:/docker-data/unms$ cat docker-compose.yml 
version: '2'
services:
  unms:
    container_name: unms-controller
    image: nico640/docker-unms:latest
    restart: always
    ports:
      - 5080:80
      - 7443:443
      - 3055:2055/udp
    environment:
      - TZ=America/New_York
      - PUBLIC_HTTPS_PORT=7443
      - PUBLIC_WS_PORT=7443
      - SSL_CERT=unms.ad.mydomain.com.crt
      - SSL_CERT_KEY=unms.ad.mydomain.com.key
    volumes:
      - /docker-data/unms:/config

Edit: I do see where it's creating user unms as 1001 so the permissions seem to be correct however it's still giving an error when trying to load the cert

2021-04-15T05:26:39.815605881Z Enabling UNMS https and wss connections on port 443
2021-04-15T05:26:39.842612443Z Updating custom certificate.
2021-04-15T05:26:39.843278836Z mv: cannot create regular file '/cert/custom.key': Permission denied
2021-04-15T05:26:39.843406596Z No certificate found.
2021-04-15T05:26:39.843421334Z Failed to copy key.
2021-04-15T05:26:39.843508999Z Generating self-signed certificate for 'localhost'.
2021-04-15T05:26:40.099571199Z Failed to generate self-signed certificate for 'localhost'
2021-04-15T05:26:40.121809387Z 2021/04/15 01:26:40 [emerg] 681#681: open() "/etc/nginx/ip-whitelist.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/unms-https+wss.conf:36
2021-04-15T05:26:40.121832471Z nginx: [emerg] open() "/etc/nginx/ip-whitelist.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/unms-https+wss.conf:36
2021-04-15T05:26:40.297209580Z Waiting for pid file '/var/lib/rabbitmq/mnesia/rabbit@4bc5d51990fa.pid' to appear
2021-04-15T05:26:40.298205524Z pid is 365
2021-04-15T05:26:40.298234279Z Waiting for erlang distribution on node 'rabbit@4bc5d51990fa' while OS process '365' is running
2021-04-15T05:26:40.306366953Z Error:
2021-04-15T05:26:40.306387351Z process_not_running
2021-04-15T05:26:40.312840374Z Starting unms-netflow...
2021-04-15T05:26:40.737545857Z Starting nginx...
2021-04-15T05:26:40.738197984Z Running entrypoint.sh
2021-04-15T05:26:40.745804137Z Updating custom certificate.
2021-04-15T05:26:40.748981356Z Entrypoint finished
2021-04-15T05:26:40.748993098Z Calling exec 

However it does actually create the custom.crt file with contents of my crt file from the usercert folder. The custom.key file though is created and when viewed with sudo has the correct contents. I stopped the container and changed the permissions on it to

administrator@docker01:/docker-data/unms/cert$ ls -l
total 8
-rw-r--r-- 1 1001  1001 1631 Apr 15 01:26 custom.crt
-rw-r--r-- 1 1001  1001 1704 Apr 15 01:26 custom.key
lrwxrwxrwx 1 1001 65533   12 Apr 15 01:27 live.crt -> ./custom.crt
lrwxrwxrwx 1 1001 65533   12 Apr 15 01:27 live.key -> ./custom.key

Restarted the container and it read the contents of the key file without error

2021-04-15T05:52:04.076892399Z Starting nginx...
2021-04-15T05:52:04.090555015Z Running entrypoint.sh
2021-04-15T05:52:04.092192461Z Will use existing SSL certificate

However I'm still getting a invalid certificate error. When I view the certificate it shows it's my certificate, but when viewing the details it doesn't show the hierarchy like it does viewing the details on the certificates on my other services. It just shows the cert it self not the root or sub ca. Like it's still not importing something correctly. Unfortunately I'm not versed enough in certs to verify that though.

[mandarvl]

I run into the same issue with the 2.3.57 version, did you manage to solve this ?

[meesteridle]

I run into the same issue with the 2.3.57 version, did you manage to solve this ?

Here is an example from my compose file. This setup works well for me.

I'm using a third-party-signed cert. I'm using the full chain as well. My unms.crt contains my signed cert at the top of unms.crt and intermediate/root at the bottom of unms.crt. Also, I'm using ecdsa key, so you know it will will work rsa keys or ecdsa keys.

Contents of unms.crt

-----BEGIN CERTIFICATE-----
MII… my signed cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MII… intermediate cert
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MII… root cert
-----END CERTIFICATE-----

Compose file

services:
  unms:
    container_name: unms
    environment:
      - TZ=America/Chicago
      - SSL_CERT=custom.crt
      - SSL_CERT_KEY=custom.key
    hostname: unms
    image: nico640/docker-unms:latest
    ports:
      - 2055:2055/udp
      - 443:443
      - 80:80
    restart: always
    volumes:
      - unms_data:/config
      - /home/bradt/Docker/SSL/[example.org]/unms.key:/usercert/custom.key:ro
      - /home/bradt/Docker/SSL/[example.org]/unms.crt:/usercert/custom.crt:ro

volumes:
  unms_data:
    external: true