2.15 problem with owncert

I have currently a fully working version of OpenVidu 2.14 in our data center using letsencrypt for developing and testing an app we developed using OpenVidu. We are ready for more extensive testing and we choose to instal OpenVidu2.15 and use our certificate on a different server using a the Docker deployment for a vanilla system. We got our certificates and place in the suggested folder “/opt/openvidu/owncert”. Configuration file .env modified to use owncert and open all ports, currently the ufw is disabled.

openVidu started with the expected .env not found error and a warning about SERVER_PORT (which I don’t understand):

[WARN] 2020-07-30 16:47:27,205 [main] io.openvidu.server.OpenViduServer - You have set property server.port (or SERVER_PORT). This will serve OpenVidu Server on your host at port 5443. But property HTTPS_PORT (443) still configures the port that should be used to connect to OpenVidu Server from outside. Bear this in mind when configuring a proxy in front of OpenVidu Server.

The problem is that connections to the server from client web are being rejected with “ERR_CONNECTION_REFUSED”.

Here is the configuration reflected by the openVidu start command:
openvidu-server_1 | Configuration properties
openvidu-server_1 | ------------------------
openvidu-server_1 |
openvidu-server_1 | * CERTIFICATE_TYPE=owncert
openvidu-server_1 | * DOMAIN_OR_PUBLIC_IP= xxx.xxxx.xxxx <------(will provide upon request)
openvidu-server_1 | * HTTPS_PORT=443
openvidu-server_1 | * KMS_URIS=[“ws://localhost:8888/kurento”]
openvidu-server_1 | * OPENVIDU_CDR=false
openvidu-server_1 | * OPENVIDU_CDR_PATH=/opt/openvidu/cdr
openvidu-server_1 | * OPENVIDU_RECORDING=false
openvidu-server_1 | * OPENVIDU_RECORDING_AUTOSTOP_TIMEOUT=120
openvidu-server_1 | * OPENVIDU_RECORDING_COMPOSED_URL=
openvidu-server_1 | * OPENVIDU_RECORDING_CUSTOM_LAYOUT=/opt/openvidu/custom-layout
openvidu-server_1 | * OPENVIDU_RECORDING_DEBUG=false
openvidu-server_1 | * OPENVIDU_RECORDING_NOTIFICATION=publisher_moderator
openvidu-server_1 | * OPENVIDU_RECORDING_PATH=/opt/openvidu/recordings
openvidu-server_1 | * OPENVIDU_RECORDING_PUBLIC_ACCESS=false
openvidu-server_1 | * OPENVIDU_RECORDING_VERSION=2.15.0
openvidu-server_1 | * OPENVIDU_SECRET=MITEM_SECRET
openvidu-server_1 | * OPENVIDU_SESSIONS_GARBAGE_INTERVAL=900
openvidu-server_1 | * OPENVIDU_SESSIONS_GARBAGE_THRESHOLD=3600
openvidu-server_1 | * OPENVIDU_STREAMS_VIDEO_MAX_RECV_BANDWIDTH=1000
openvidu-server_1 | * OPENVIDU_STREAMS_VIDEO_MAX_SEND_BANDWIDTH=1000
openvidu-server_1 | * OPENVIDU_STREAMS_VIDEO_MIN_RECV_BANDWIDTH=300
openvidu-server_1 | * OPENVIDU_STREAMS_VIDEO_MIN_SEND_BANDWIDTH=300
openvidu-server_1 | * OPENVIDU_WEBHOOK=false
openvidu-server_1 | * OPENVIDU_WEBHOOK_ENDPOINT=
openvidu-server_1 | * OPENVIDU_WEBHOOK_EVENTS=[sessionCreated,sessionDestroyed,participantJoined,participantLeft,webrtcConnectionCreated,webrtcConnectionDestroyed,recordingStatusChanged,filterEventDispatched,mediaNodeStatusChanged]
openvidu-server_1 | * OPENVIDU_WEBHOOK_HEADERS=[]

The “netstat -lntup” gives the following: (note that 443 is missing)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 10720/nginx: master
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 867/systemd-resolve
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 172.17.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 10.65.1.202:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN 10855/turnserver
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 964/sshd: /usr/sbin
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 10896/redis-server
tcp6 0 0 :::22 :::* LISTEN 964/sshd: /usr/sbin
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 ::1:3478 :::* LISTEN 10855/turnserver
tcp6 0 0 :::8888 :::* LISTEN 10805/kurento-media
tcp6 0 0 :::5442 :::* LISTEN 10678/node
tcp6 0 0 :::9090 :::* LISTEN 1120/prometheus
tcp6 0 0 :::5443 :::* LISTEN 10653/java
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 172.17.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 10.65.1.202:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.1:3478 0.0.0.0:* 10855/turnserver
udp 0 0 127.0.0.53:53 0.0.0.0:* 867/systemd-resolve
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver
udp6 0 0 ::1:3478 :::* 10855/turnserver

and the “docker-compose logs -f nginx”:

nginx_1 |
nginx_1 | =======================================
nginx_1 | = INPUT VARIABLES =
nginx_1 | =======================================
nginx_1 |
nginx_1 | Config NGINX:
nginx_1 | - Http Port: 80
nginx_1 | - Https Port: 443
nginx_1 | - Allowed Access in Openvidu Dashboard: all
nginx_1 | - Allowed Access in Openvidu API: all
nginx_1 |
nginx_1 | Config Openvidu Application:
nginx_1 | - Domain name: xxx.xxxx.xxxx
nginx_1 | - Certificated: owncert
nginx_1 | - Letsencrypt Email:
nginx_1 | - Openvidu Application: true
nginx_1 | - Openvidu Application Type: CE
nginx_1 |
nginx_1 | =======================================
nginx_1 | = CONFIGURATION NGINX =
nginx_1 | =======================================
nginx_1 |
nginx_1 | Configure (will provide upon request) domain…
nginx_1 | - New configuration: owncert
nginx_1 | - Old configuration: owncert
nginx_1 | - Owmcert certificate already exists, using them…
nginx_1 |
nginx_1 | =======================================
nginx_1 | = ALLOWED ACCESS =
nginx_1 | =======================================
nginx_1 |
nginx_1 | Adding rules…
nginx_1 |
nginx_1 | Finish Rules:
nginx_1 | Openvidu Dashboard:
nginx_1 | - allow all;
nginx_1 | Openvidu API:
nginx_1 | - allow all;
nginx_1 |
nginx_1 | =======================================
nginx_1 | = START OPENVIDU PROXY =
nginx_1 | =======================================
nginx_1 |
nginx_1 | 2020/07/30 16:47:26 [emerg] 63#63: cannot load certificate “/etc/letsencrypt/live/crtc.mitem.com/fullchain.pem”: PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE)
nginx_1 | nginx: [emerg] cannot load certificate “/etc/letsencrypt/live/crtc.mitem.com/fullchain.pem”: PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE)
nginx_1 | 2020/07/30 16:48:20 [error] 11#11: *1 “/etc/nginx/html/index.html” is not found (2: No such file or directory), client: 96.86.174.45, server: , request: “GET / HTTP/1.1”, host: “crtc.mitem.com
nginx_1 | 2020/07/30 16:48:20 [error] 11#11: *1 open() “/etc/nginx/html/favicon.ico” failed (2: No such file or directory), client: 96.86.174.45, server: , request: “GET /favicon.ico HTTP/1.1”, host: “xxxx.xxxxx.xxxxx”, referrer: “http:/xxxx.xxxx.xxxx/”
nginx_1 | 2020/07/30 16:48:38 [error] 11#11: *2 “/etc/nginx/html/index.html” is not found (2: No such file or directory), client: 76.220.16.161, server: , request: “GET / HTTP/1.1”, host: “xxxx.xxx.xxxx”
nginx_1 | 2020/07/30 16:48:42 [error] 11#11: *2 “/etc/nginx/html/index.html” is not found (2: No such file or directory), client: 76.220.16.161, server: , request: “GET / HTTP/1.1”, host: “xxxx.xxx.xxxx”

==============================================================

I am completely confused, on what I am doing wrong? Can you please help!

Thanks

1 Like

Some more information:

I don’t have the apache or the nginx installed on this server.
There is’t a letsencypt folder in /etc since I did not specify the letsencrypt in the .env and I am confused on why openvidu is looking for a letsencrypt certificate?

I have the following files in the owncert:

certificate.cert
certificate.key
crtc.csr
crtc.key
crtc.pem

where the certificate.cert is the same as cert.pem and the same for the key file; I renamed them based on the suggestion in the .env:

- owncert: Valid certificate purchased in a Internet services company.

Please put the certificates files inside folder ./owncert

with names certificate.key and certificate.cert

Is it possible that I am having certificate naming problems?

1 Like

Just commenting to express that I am having an identical issue.

It seems as though there is a bug that always reverts to letsencrypt, these are my nginx logs

Hi Garvan,

Glad I am not alone! I have tried everything, the certificate and the key file are OK. The key file is not password protected and I can’t think of any reason for the service to look for a letsencrypt certificate.

There must be more people having this problem, but I could not find any other comments in the forum with a similar problem.

My experience with OpenVidu 2.14 has been excellent so far with no “bugs” or glitches…

It seems there are some problem with NGINX trying to open the provided certificate.

Can you check NGINX documentation to see what is the expected certificate format and try again?

The certificate must be encoded in PEM format. Please take a look to this web page for more information

https://documentation.progress.com/output/DataDirect/hybridpipeinstall/index.html#page/install/pem-file-format.html

  • certificate.key is the private key and must follow this format:
-----BEGIN PRIVATE KEY-----
<BASE64_PRIVATE_KEY>
-----END PRIVATE KEY-----
  • certificate.cert are the public keys and must follow this format:
-----BEGIN CERTIFICATE-----
<BASE64_PUBLIC_KEY>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<BASE64_PUBLIC_KEY>
-----END CERTIFICATE-----
...

Normally official certificates have a chain of public keys in the .cert

Please verify that your files follow this format. (PEM format)

The certificate is a PEM certificate, this is the format of the certificate.cert in the ./owncert:

-----BEGIN CERTIFICATE-----
MIIGIjCCBQqgAwIBAgIQDnbR9skWfI7McJlSWoDOsTANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E

p2I7WGZYv7LzLI8q4IS2T2uI0bA5G2bTtlLM7nZH92gH5SpsDR4=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIElDCCA3ygAwIBAgIQAf2j627KdciIQ4tyS8+8kTANBgkqhkiG9w0BAQsFADBh

j6tJLp07kzQoH3jOlOrHvdPJbRzeXDLz
-----END CERTIFICATE-----

the problem is that the error in the nginx log file mentions missing “TRUSTED” which I think it means is looking for:
-----BEGIN TRUSTED CERTIFICATE-----

which indicates is looking for a self-generated certificated not one with a “chain of trust”

One difference, my certificate.key has the RSA in the first line:

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEA7rZlJo1wVvqis1zkW/vPizINEqGzUCjtEOvr7IBMO34C42CG
+jKwEa6PzahPeSpc3dS1/OiHtd/WdhkO5yHwk+LVQvmrXlamNVtLSDzw54+sPWj9

wP42CDdhF2B8IbnPvDDg3CJxgu+2LfU46pJXAm8RWeOwuWwnjUU=
-----END RSA PRIVATE KEY-----

That could be the problem. What happens if you change -----BEGIN RSA PRIVATE KEY----- by -----BEGIN PRIVATE KEY-----? (change also the end)

I mean, you need to convert the private key to PEM format, not use RSA:

openssl rsa -in <path-to-key-file> -text <path-to-PEM-file>

Removing RSA does nothing different.

Trying to convert to PEM by different suggestions:

For this I got an error (it needs ‘> certificate.key’)
sudo openssl rsa -in crtc.key -text certificate.key
rsa: Use -help for summary.

Trying:

sudo openssl rsa -in crtc.key -text > certificate.key
produces a weird result that starts with:

SA Private-Key: (2048 bit, 2 primes)
modulus:
00:ee:b6:65:26:8d:70:56:fa:a2:b3:5c:e4:5b:fb:

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEA7rZlJo1wVvqis1zkW/vPizINEqGzUCjtEOvr7IBMO34C42CG

wP42CDdhF2B8IbnPvDDg3CJxgu+2LfU46pJXAm8RWeOwuWwnjUU=
-----END RSA PRIVATE KEY-----

Also tried:

sudo openssl rsa -in crtc.key -outform pem > certificate.key
that just copy the croc.key to certificate.key

I am going to revoke the current certificates and start all over again… making sure the a have a pem key

One question about nginx since I am not that familiar, if the certificates are not valid nginx will not start listening on either port 80 or 443? Is that true?

hey @aurdoc i solves this issues max time people have ssl problems . please go step by step and if you need help ping me
Thanks

I’m not sure… test it yourself

Summary of today:

  1. Create new certificate from scratch and applied dos2unix hack to make sure there are no ^M chars in the file - made no difference

  2. Verified certificate.cert with command: “openssl x509 -text -noout -in certificate.cert” which proves the certificate is a valid .pem certificate with no errors. The .key file does not have the RSA in the -----BEGIN PRIVATE KEY-----

  3. More research on the error in the “docker-compose logs -f nginx”:

.cannot load certificate “/etc/letsencrypt/live/crtc.mitem.com/fullchain.pem”: PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE)

  • lead me to the following site:
  • has a description for Nginx PEM_read_bio_X509_AUX: Expecting: TRUSTED CERTIFICATE which indicates that the error happens if the .key and .crt files are reversed or the nginx configuration file has them reversed…
    … to test this I did reverse the files but with no positive effect
  1. I notice that the Nginx PEM_read_bio_X509_AUX(): error is supposed to have the path to the certificate.cert between the parenthesis - but the path is missing in the AUX()… Is this an error in the nginx docke-compose configuration? … I am not that familiar with docker-composer to check! …can you verify?

  2. On starting openvidu I do get a warning:

io.openvidu.server.OpenViduServer - You have set property server.port (or SERVER_PORT). This will serve OpenVidu Server on your host at port 5443. But property HTTPS_PORT (443) still configures the port that should be used to connect to OpenVidu Server from outside. Bear this in mind when configuring a proxy in front of OpenVidu Server

  • I don’t know how to interpret this warning, there is no proxy in front so I was ignoring but could it provide a clue…
  • the only changes I made to .env are:
    DOMAIN_OR_PUBLIC_IP=xxxx.xxx.xxx
    OPENVIDU_SECRET=xxxxx_xxxx
    CERTIFICATE_TYPE=owncert
    and did not touch anything else…
  1. Conclusion: I learned a lot about certificates, but have made no progress. Any suggestion what I should do next?

Thanks!

Let’s try this @aurdoc. I don’t know if you’ve tried what I’m going to say but let’s give it a try. I think, as @Garvan_Doyle said, it seems like there are some problems changing the property CERTIFICATE_TYPE.

  1. Delete /opt/openvidu/certificates
  2. Make sure that certificate.cert has the puclic keys and certificate.key the private key in /opt/openvidu/owncert.
  3. Run as sudo ./openvidu restart.

I hope this helps. If not, please review this little guide. I’m actually mantaining an OpenVidu Pro instance using a GoDaddy certificate and two OpenVidu deployments with letsencrypt without problems.
Steps to generate a certificate from a commercial CA I’ve followed:

  1. Create a CSR and a private key (I think that is the step you did). This can be easily done by executing:

    openssl req -newkey rsa:2048 -nodes -keyout certificate.key -out certificate.csr

    Also ensure that all data is correctly inserted (Common Name, Organization Name, etc…). The most important part is the Common Name field which should match the name that you want to use your certificate with–for example, example.com , www.example.com , or *.example.com. The last one should be use if you have a WildCart certificate.
  2. The previous command generated the certificate.key. The certificate.csr is the file that you need to provide to your CA. Depending of your CA this step can differ.
  3. Usually the files to generate the certificate.cert can be downloaded or are sended via email. You should have two files:
  • The intermediate certificate. (It usually have more than one key with ---BEGIN CERTIFICATE--- This file will be called as intermediate.cert in following steps.
  • Your ssl certificate. An unique certificate key with ---BEGIN CERTIFICATE---. This file will be called as public.cert in following steps.

  1. You need to concat these two files in an unique certificate.cert file in this way:

    cat public.cert intermediate.crt > certificate.cert

  2. Now you have the certificate.key generated in step 1. and the certificate.cert generated in step 4. Copy it to /opt/openvidu/owncert and execute: ./openvidu restart
    If I did not explain correctly, I usually use this guide to setup SSL Certificates: https://www.digitalocean.com/community/tutorials/how-to-install-an-ssl-certificate-from-a-commercial-certificate-authority.

I hope this answer helps you to solve your problem. Please if this does not help you, notice it here.

Thanks Cruizba,

First I confirmed my certificates are OK, that is not the problem.

The problem appears to be due to my network configuration and the Ubuntu resolver.

We do have one implementation of OpenVidu in our data center which as I mentioned before works without a problem. In that configuration the server has direct access to internet via a dedicated public address.

In this case I installed an Ubuntu 20.04 server in my office on the intranet and configured the gateway with a fixed public address mapped to my server… and this configuration is what fails. To make the story short the failure appears to be due to miss-mapping of the DNS public address and the nginx view of its public address which is the local intranet address and not the public address. See:

https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/

Just for clarity we defined a DNS domain name for our installation with a dedicated public address and mapped that public IP address (with all its ports) to the local address of my server in the gateway.

I tried messing with the resolvconf.service and dnsmaskq but this also required reconfiguring the nginx inside docker and I am not that familiar with sshd and so I found it easier to re-wire the building with a new ethernet cable to eliminate the intranet.

We accomplished it late last night and I am glad to report that openvidu 2.15 docker installation went without a hitch and with my certificates I now have a fully working OpenVidu 2.15 environment.

I can’t say I solve my original problem, but I believe that a direct connection to the internet is required, and I think that many problem reported by others here may be do to the same network topology.

And I would like to mentioned the superb effort you are all making to support your product and I thank you for that!

1 Like

So I was getting the same error.
What I noticed was that after I ran openvidu with “selfsigned” enabled once in the .env file. The .conf file in /opt/openvidu/certificates was set to “selfsigned” even after I changed to “owncert” in the .env file and ran openvidu.

I deleted the opt/openvidu/certificates folder, ran openvidu and the problem stopped.