# 2.15 problem with owncert

**URL:** https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677
**Category:** Issues with deployment
**Tags:** v2
**Created:** [July 30, 2020, 5:52pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677 "2020-07-30T17:52:33Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 30, 2020, 5:52pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/1 "2020-07-30T17:52:33Z")

</div>

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](http://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

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 30, 2020, 10:48pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/2 "2020-07-30T22:48:55Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![Garvan\_Doyle](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/garvan_doyle/32/800_2.png) [@Garvan\_Doyle](https://openvidu.discourse.group/u/Garvan_Doyle)
#### Post date: [July 30, 2020, 10:50pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/3 "2020-07-30T22:50:47Z")

</div>

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

 ![tryingToUseLetsencrypt](https://global.discourse-cdn.com/free1/uploads/openvidu/original/1X/a7c081000fd8d0f9c2d1897e77a3a65b3d59fd37.png) ![usingOwnCert](https://global.discourse-cdn.com/free1/uploads/openvidu/original/1X/201295a58120c486674c3bcc088c47c925b5e20d.png)

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 31, 2020, 12:06am UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/4 "2020-07-31T00:06:59Z")

</div>

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…

---

<div class="post-metadata">

### Author: ![micael.gallego](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/micael.gallego/32/2_2.png) [@micael.gallego](https://openvidu.discourse.group/u/micael.gallego)
#### Post date: [July 31, 2020, 12:00pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/5 "2020-07-31T12:00:37Z")

</div>

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

> [@aurdoc](#):
>
> 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)

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

---

<div class="post-metadata">

### Author: ![micael.gallego](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/micael.gallego/32/2_2.png) [@micael.gallego](https://openvidu.discourse.group/u/micael.gallego)
#### Post date: [July 31, 2020, 2:34pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/6 "2020-07-31T14:34:12Z")

</div>

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](https://documentation.progress.com/output/DataDirect/hybridpipeinstall/index.html#page/install/pem-file-format.html)

---

<div class="post-metadata">

### Author: ![cruizba](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/cruizba/32/18_2.png) [@cruizba](https://openvidu.discourse.group/u/cruizba)
#### Post date: [July 31, 2020, 2:52pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/7 "2020-07-31T14:52:23Z")

</div>

- _`certificate.key` is the private key and must follow this format:_

```auto
-----BEGIN PRIVATE KEY-----
<BASE64_PRIVATE_KEY>
-----END PRIVATE KEY-----

```

- _`certificate.cert`_ are the public keys and must follow this format:

```auto
-----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)

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 31, 2020, 3:09pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/8 "2020-07-31T15:09:25Z")

</div>

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”

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 31, 2020, 3:18pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/9 "2020-07-31T15:18:12Z")

</div>

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

---

<div class="post-metadata">

### Author: ![cruizba](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/cruizba/32/18_2.png) [@cruizba](https://openvidu.discourse.group/u/cruizba)
#### Post date: [July 31, 2020, 3:18pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/10 "2020-07-31T15:18:57Z")

</div>

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

---

<div class="post-metadata">

### Author: ![cruizba](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/cruizba/32/18_2.png) [@cruizba](https://openvidu.discourse.group/u/cruizba)
#### Post date: [July 31, 2020, 3:23pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/11 "2020-07-31T15:23:44Z")

</div>

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

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 31, 2020, 3:46pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/12 "2020-07-31T15:46:49Z")

</div>

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

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 31, 2020, 4:00pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/13 "2020-07-31T16:00:10Z")

</div>

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

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [July 31, 2020, 4:02pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/14 "2020-07-31T16:02:28Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![vipin\_mishra](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/vipin_mishra/32/32_2.png) [@vipin\_mishra](https://openvidu.discourse.group/u/vipin_mishra)
#### Post date: [July 31, 2020, 4:37pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/15 "2020-07-31T16:37:22Z")

</div>

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

---

<div class="post-metadata">

### Author: ![micael.gallego](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/micael.gallego/32/2_2.png) [@micael.gallego](https://openvidu.discourse.group/u/micael.gallego)
#### Post date: [July 31, 2020, 4:47pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/16 "2020-07-31T16:47:05Z")

</div>

I’m not sure… test it yourself

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [August 1, 2020, 12:25am UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/17 "2020-08-01T00:25:55Z")

</div>

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.cer** t” 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:

> **[Nginx SSL Certificate Errors: PEM\_read\_bio\_X509\_AUX, PEM\_read\_bio\_X509,...](https://ma.ttias.be/nginx-ssl-certificate-errors-pem_read_bio_x509_aux-pem_read_bio_x509-ssl_ctx_use_privatekey_file/)**
>
> When configuring your SSL certificates on Nginx, it’s not uncommon to see several errors when you try to reload your Nginx configuration, to activate the SSL Certificates.

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

---

<div class="post-metadata">

### Author: ![cruizba](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/cruizba/32/18_2.png) [@cruizba](https://openvidu.discourse.group/u/cruizba)
#### Post date: [August 4, 2020, 10:28pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/19 "2020-08-04T22:28:09Z")

</div>

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

---

<div class="post-metadata">

### Author: ![aurdoc](https://avatars.discourse-cdn.com/v4/letter/a/ecae2f/32.png) [@aurdoc](https://openvidu.discourse.group/u/aurdoc)
#### Post date: [August 5, 2020, 1:16pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/20 "2020-08-05T13:16:00Z")

</div>

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/](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!

---

<div class="post-metadata">

### Author: ![Kevin\_D](https://yyz2.discourse-cdn.com/free1/user_avatar/openvidu.discourse.group/kevin_d/32/907_2.png) [@Kevin\_D](https://openvidu.discourse.group/u/Kevin_D)
#### Post date: [August 18, 2020, 3:02pm UTC](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677/21 "2020-08-18T15:02:44Z")

</div>

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.

[Next page](https://openvidu.discourse.group/t/2-15-problem-with-owncert/1677.md?page=2)