Hello,
I am using CouchDB and trying to issue a certificate for my domain. NOTE: my domain isn't being hit by the rate limit, I verified it. (I'll refer to my domain as "the.actual.domain") I'm also using the --test-cert flag, to not create useless production certs.
The issue is that I can't seem to make it work. When I read the CouchDB docs about SSL, I understand that the service has it's own webserver, so it can handle certificates. I tried to generate Let's encrypt certificates for my domain, which I then specified the files path into my CouchDB config (as specified in their docs). Restarted, then tried to go to my machine
I ran this command:
Certificate not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /opt/couchdb/letsencrypt/renewal/the.actual.domain.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for the.actual.domain
Successfully received certificate.
Certificate is saved at: /opt/couchdb/letsencrypt/live/the.actual.domain/fullchain.pem
Key is saved at: /opt/couchdb/letsencrypt/live/the.actual.domain/privkey.pem
This certificate expires on 2022-06-03.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Using lighttpd v1.4.64 as webserver
The server runs Ubuntu 20.04
The server machine is hosted at DigitalOcean
I can login as root.
Using certbot v1.24.0
//
Could someone point out some guidelines on how I can setup an SSL certificates for a CouchDB server?
Any help is appreciated, and don't hesitate to ask for more information.
where /etc/couchdb/cert/couchdb.pem is replaced by the Let's Encrypt fullchain.pem and /etc/couchdb/cert/privkey.pem is replaced by the Let's Encrypt privkey.pem? And then restarted or reloaded CouchDB?
And what kind of error or behavior do you see after that when trying to connect?
It seems in the CouchDB documentation that they were envisioning that you use CouchDB as its own web server, not an external one, or did I misunderstand that?
Oh my, thanks for the fast reply.
Indeed, I did all the steps as described in their docs (just like you described in your message). I also tried with and without lighttpd, and both methods didn't work.
Without lighttpd: I removed the flag --webroot -w /var/www/html to have this command;
Saving debug log to /opt/couchdb/var/log/letsencrypt.log
How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Certificate not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /opt/couchdb/letsencrypt/renewal/the.actual.domain.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for the.actual.domain
Successfully received certificate.
Certificate is saved at: /opt/couchdb/letsencrypt/live/the.actual.domain/fullchain.pem
Key is saved at: /opt/couchdb/letsencrypt/live/the.actual.domain/privkey.pem
This certificate expires on 2022-06-03.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
When I try to connect, I get an SSL_ERROR_SYSCALL, without more information.
The thing is, I don't really know what the precise steps are to setup a certificate for CouchDB, whether I'm using it's own web server or another.
P.S
I also tried a self signed certificate, and it works, but that is of no use in a production environment.
Maybe I am not generating the certificates the proper way?
The last method I tried is generating a Let's Encrypt standalone cert, and as described in CouchDB docs, specify the path to the files in the config. I also verified, and couchdb has full permissions over these files.
Managed to make it work by using nginx.
Now I don't have anymore issues with certificate issuance. I just need to find path to my webroot for nginx, as if I go to https://the.actual.domain/_utils, I get a 404. (./_utils being the homepage of CouchDB)
Which describes some details of your installation. Up to there, nothing extraordinary. Now, if I try to go to https://the.actual.domain/_utils (_utils being the dashboard of CouchDB), I land on a 404 from nginx. Which makes me assume that I put the wrong web root path in the nginx config?
None, you should not have a root there. You already have a proxy_pass directive, I am not even sure about the try_files directive.
My similar config looks like this:
upstream lampone {
server 10.9.1.5 max_fails=0; # wireguard
server 10.9.0.5 max_fails=0 backup; # tinc
}
server {
server_name lampone.example.com;
include snippets/listen;
include snippets/ssl_conf;
include snippets/ssl_cert_lampone;
location / {
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
try_files $uri $uri/ @lampone; # <- this is location lampone
}
location @lampone {
proxy_pass http://lampone; # <- this is upstream lampone
include snippets/proxy_conf;
}
}
When I just tried to install CouchDB and point it to my Certbot certificate, it fails when I try and connect on the SSL port. Tracing what CouchDB is doing, the issue is indeed due to permissions: