Docker-jitsi-meet: Use own existing SSL cert

Created on 9 Apr 2020  路  10Comments  路  Source: jitsi/docker-jitsi-meet

Hi there,

instead of enabling Let's encrypt cert (generation), I would like to use my own. Is this somehow possible? I didn't found a setting that would allow me that.

thanks and all the best
Martin

Most helpful comment

I created a quick and dirty solution that I am using. I put my own SSL certs in a folder ~/ssl and run this command

sudo cp ~/ssl/cert.* ~/.jitsi-meet-cfg/web/keys/

Make sure the certs are name cert.key and cert.crt. You might have to reboot the nginx container but if I remember correctly nginx picks up the new certs almost immediatly.

All 10 comments

i now tried with enabling:

ENABLE_LETSENCRYPT
LETSENCRYPT_DOMAIN
and
LETSENCRYPT_EMAIL

and the cert is generated just fine. It is inside the container. However when i visit my subdomain it still says that I have a invalid certificate. Tried to restart docker container several times, tried to also delete the container an re-create, but doesn't work. Not sure but to me it seem like there is an issue with templating or so. Can this be?

Update:

When I execute this command directly in the container:

tpl /defaults/ssl.conf > /config/nginx/ssl.conf

Then the templating works.

Probably the file /config/nginx/ssl.conf already exists in the jitsi/web container and therefor the templating does not take place see:

https://github.com/jitsi/docker-jitsi-meet/blob/a4274840e1e158950a6b86f0ff92368434d67fc2/web/rootfs/etc/cont-init.d/10-config#L64

one would need to manually delete it on the volume mount

The easiest and most lightweight way is to utilize haproxy; edit /etc/haproxy/haproxy.cfg:

    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     3000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
defaults
    option forwardfor
    option http-server-close

    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms

frontend www-http
  bind  *:80
  redirect scheme https code 301 if !{ ssl_fc }
frontend www-https
    bind INSERT_YOUR_IP:443 ssl crt /etc/haproxy/certs/FQDN.pem
    reqadd X-Forwarded-Proto:\ https
    http-request set-header X-SSL %[ssl_fc]
    default_backend www-backend
backend www-backend
   redirect scheme https code 301 if !{ ssl_fc }
   server www-1 127.0.0.1:8000 check

Get your certificates and do a:

DOMAIN='FQDN' sudo -E bash -c 'cat /etc/letsencrypt/live/FQDN/fullchain.pem /etc/letsencrypt/live/FQDN/privkey.pem > /etc/haproxy/certs/FQDN.pem'

Then start your HAproxy and Jitsi and you're done.

I created a quick and dirty solution that I am using. I put my own SSL certs in a folder ~/ssl and run this command

sudo cp ~/ssl/cert.* ~/.jitsi-meet-cfg/web/keys/

Make sure the certs are name cert.key and cert.crt. You might have to reboot the nginx container but if I remember correctly nginx picks up the new certs almost immediatly.

The .env does define a CONFIG variable which is pointing per default to ~/.jitsi-meet-cfg``which (on Windows at least) is inuser-folder/.jitsi-meet-cfg` after using the readme to the the setup.

In there (for example C:\Users\username\.jitsi-meet-cfg\web\keys) you will find two key files which you can simply replace with your own ones.

I created a quick and dirty solution that I am using. I put my own SSL certs in a folder ~/ssl and run this command

sudo cp ~/ssl/cert.* ~/.jitsi-meet-cfg/web/keys/

Make sure the certs are name cert.key and cert.crt. You might have to reboot the nginx container but if I remember correctly nginx picks up the new certs almost immediatly.

This is not the quick and dirty solution. It is intended to be done like this!

I created a quick and dirty solution that I am using. I put my own SSL certs in a folder ~/ssl and run this command
sudo cp ~/ssl/cert.* ~/.jitsi-meet-cfg/web/keys/
Make sure the certs are name cert.key and cert.crt. You might have to reboot the nginx container but if I remember correctly nginx picks up the new certs almost immediatly.

This is not the quick and dirty solution. It is intended to be done like this!

Is it really the intended version? If I am using a wildcard certificate I have to copy the cert all the time it is renewed or symlink it. It feels like some additional afford.
It would be great to set a certificate path on our own.

I am not part of this prject, but from reading the .env file I expect that the recommended solution is to use Let's encrypt.
The solution to use an own cert is to set it in the config folder. Everything else would be workarounds.

  • Directly put your path in cert.conf
  • Add symlinks from ~/.jitsi-meet-cfg/web/keys to your cert folder.
  • And in worst case it is not impossible to automate the copying of the cert files.

Useing your SSL cert is not supported in this setup. Please see: https://github.com/jitsi/docker-jitsi-meet/issues/359#issuecomment-607414369

I created a quick and dirty solution that I am using. I put my own SSL certs in a folder ~/ssl and run this command

sudo cp ~/ssl/cert.* ~/.jitsi-meet-cfg/web/keys/

Make sure the certs are name cert.key and cert.crt. You might have to reboot the nginx container but if I remember correctly nginx picks up the new certs almost immediatly.

This works for me

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mikemorris picture mikemorris  路  8Comments

chovy picture chovy  路  11Comments

0187773933 picture 0187773933  路  7Comments

tsproesser picture tsproesser  路  8Comments

ErrorInPersona picture ErrorInPersona  路  3Comments