Month: May 2021

In this example using Letsencrypt SSL certificates. The webservice is behind HAProxy and was not been able to successfully configure HAProxy to update Letsencrypt certificates over HTTP. Therefore, I manually updated the certificate.
/etc/webservice/tls/server.crt _> /etc/letsencrypt/live/site.com/cert.pem

/etc/webservice/tls/server.key -> /etc/letsencrypt/live/site.com/privkey.pem.

After updating the certificates, I linked the original to the new certificates in the Letencrypt folder:
When I try to connect to the webservice, I get this error message sent an invalid response. ERR_SSL_PROTOCOL_ERROR’.

The destination of his symlink, not the symlink itself, needs to be readable by the nvrweb user. In this example the directory that the symlink did not have permissions to allow the link to work correctly.

The best way to be sure would be to run terminal command
sudo -i
to root and then run
su nvrweb -s /bin/bash
and try to view the files (e.g., cat the paths listed in the config file).
This should give you an out put.

{
“service”: {
“name”: “Customer Name”,
“url”: “https://site.com”,
“loginTokenExpiration”: 30,
“discoverable”: true,
“inactivityTimeout”: 0,
“enableAutocomplete”: false,
“enableRelay”: false
},
“webserver”: {
“listen”: 80,
“tls”: {
“listen”: 443,
“cert”: “/etc/webservice/tls/server.crt”,
“key”: “/etc/webservice/tls/server.key”,
“type”: “external”
}
},
“log”: {
“duration”: 1,
“interval”: “W”,
“level”: “debug”,
“retain”: 1
},
“servers”: [
{
“host”: “site.com”,
“port”: 22609,
“passthrough”: {
“enabled”: false
},
“poweruser”: {
“enabled”: true,
“username”: “INFO”,
“password”: ” INFO”
}
}
],
“nvrg”: {
“port”: 22717,
“remote”: {
“enabled”: false,
“port”: 35111
}
},
“updates”: {
“fileInfo”: “https://www.exacq.com/downloads/evFileInfo.txt”,
“downloadTimeout”: 10
},
“auth”: {
“type”: “none”

We also need to make sure nvrweb can read the cert files
/etc/webservice/tls/server.crt and .key
The output will show the certs.

nvrweb@sunstone:/root$ cd /etc/webservice
nvrweb@sunstone:/etc/webservice$ cat tls/server.crt
—–BEGIN CERTIFICATE—–
Contents of cert will be displayed here.
—–END CERTIFICATE—–

nvrweb@sunstone:/etc/webservice$ cat tls/server.key
—–BEGIN PRIVATE KEY—–
Contents of Cert will be displayed here
—–END PRIVATE KEY—–

These certs were in the TLS directory and being linked to the Letsencrypt folder, which we found having permissions issues.

To check try the following:
Try the same thing with su to nvrweb and see if nvrweb can access the certs in the let’s encrypt folder, before changes WS config.
Important to note that it’s not just the permissions of the target file that matter, but all the directories in between. In this case the target file was fine but the directory was LetsEncrypt and that did not have permissions. Since we were pointing the link to another file, that file needs to be accessible to nvrweb.

ls -ld for each directory – /etc/letsencrypt, /etc/letsencrypt/live, /etc/letsencrypt/site.com

Without -d it will show the contents, if you want to look at the directory like /etc/letsencrypt it’s necessary to do ls -ld /etc/letsencrypt

The site.com directory is fine. We need to check the live or letsencrypt directories.
letsencrypt live directory’s permissions are rwx—- which means only root can enter or read the directory.

In the above photo we can see that the Permission is denied for the letsencrypt/live folder.

Configuration this way in not the normal process and it is possible the next time I run letsencrypt again to update certs it might error due to perms or reset them. The process might need to be done each time.