Generate And Install A Let's Encrypt SSL Certificate For A Bitnami Application

Server
1

Short summary, I tested with:
curl -vsk https://admin:MyPassword@18.214.95.156:6984 (for “MyPassword” I use my actual password)
I get:

  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):
  • Unknown SSL protocol error in connection to 18.214.95.156:6984
  • Closing connection 0

The story:
I haven’t had much luck so far with the Bitnami support so I thought I’d ask here where people understand SSL. All this is new to me and I’ve spend dozens of hours on it. So I followed instructions at:
https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/
Ran:
sudo lego --email="admin@ppcjsondata.com" --domains=“ppcjsondata.com” --domains=“www.ppcjsondata.com” --path="/etc/lego" run
Looks good. Note I’m not on Apache or NGINX but bitnami server. So I also followed instructions at: https://docs.bitnami.com/aws/infrastructure/couchdb/administration/enable-ssl/
This is where I think something is wrong:
cacert_file = /full/path/to/cacertf
This is a line in the configuration of the application couchdb.
When I review instructions for couchdb v2.2.0 I see notes on the cacert_file variable. Whatever I put in this doesn’t seem to matter.
Notes there on configuration are:
cacert_file
The path to a file containing PEM encoded CA certificates. The CA certificates are used to build the server certificate chain, and for client authentication. Also the CAs are used in the list of acceptable client CAs passed to the client when a certificate is requested. May be omitted if there is no need to verify the client and if there are not any intermediate CAs for the server certificate:
[ssl]
cacert_file = /etc/ssl/certs/ca-certificates.crt

So I noticed in the error at the start of my post showed:
CApath: /etc/ssl/certs
Even if I uncomment that configuration line cacert_file = … I still get this in the error. I suspect this is the issue.
The key and certificate are in the right place:
[ssl]
port = 6984
cert_file = /opt/bitnami/couchdb/conf/server.crt
key_file = /opt/bitnami/couchdb/conf/server.key

2

The couchdb instructions I refer to are at:
https://docs.couchdb.org/en/2.2.0/config/http.html?highlight=ssl

I think the certificate creation is okay. As I stated, I think the output looks correct.
bitnami@ip-172-31-31-100:/opt/bitnami$ sudo lego --email="admin@ppcjsondata.com" --domains=“ppcjsondata.com” --domains=“www.ppcjsondata.com” --path="/etc/lego" run
2018/12/27 18:43:46 No key found for account admin@ppcjsondata.com. Generating a curve P384 EC key.
2018/12/27 18:43:46 Saved key to /etc/lego/accounts/acme-v02.api.letsencrypt.org/admin@ppcjsondata.com/keys/admin@ppcjsondata.com.key
2018/12/27 18:43:46 Please review the TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
2018/12/27 18:43:46 Do you accept the TOS? Y/n
Y
2018/12/27 18:43:49 [INFO] acme: Registering account for admin@ppcjsondata.com
2018/12/27 18:43:49 !!! HEADS UP !!!
2018/12/27 18:43:49
Your account credentials have been saved in your Let’s Encrypt
configuration directory at “/etc/lego/accounts/acme-v02.api.letsencrypt.org/admin@ppcjsondata.com”.
You should make a secure backup of this folder now. This
configuration directory will also contain certificates and
private keys obtained from Let’s Encrypt so making regular
backups of this folder is ideal.
2018/12/27 18:43:49 [INFO] [ppcjsondata.com, www.ppcjsondata.com] acme: Obtaining bundled SAN certificate
2018/12/27 18:43:50 [INFO] [ppcjsondata.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/cCBJe3v9SQc3T7KGTY2vt6xpbyp_IGzOV9ygw_ondYQ
2018/12/27 18:43:50 [INFO] [www.ppcjsondata.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/M5D0V55ZQDI8j-yU7iSFlW-NlgJoZqZgAW3kUSZ_06E
2018/12/27 18:43:50 [INFO] [ppcjsondata.com] acme: Trying to solve TLS-ALPN-01
2018/12/27 18:43:55 [INFO] [ppcjsondata.com] The server validated our request
2018/12/27 18:43:55 accept tcp [::]:443: use of closed network connection
2018/12/27 18:43:55 [INFO] [www.ppcjsondata.com] acme: Trying to solve TLS-ALPN-01
2018/12/27 18:44:01 [INFO] [www.ppcjsondata.com] The server validated our request
2018/12/27 18:44:01 accept tcp [::]:443: use of closed network connection
2018/12/27 18:44:01 [INFO] [ppcjsondata.com, www.ppcjsondata.com] acme: Validations succeeded; requesting certificates
2018/12/27 18:44:02 [INFO] [ppcjsondata.com] Server responded with a certificate.

3

Hi,

I think the CA certificate it asked is the CA chain certificate (which would help you build a chain of trust)…

I’m not sure if Lego downloaded those certificates for you on to the server… If you want that CA certificate, you could download it from here

Please make sure you downloaded the DTS cross signed certificate (because currently Let’s Encrypt still use that certificate to sign end certificates)

Thank you

4

One of the files generated is:
ppcjsondata.com.issuer.crt
Tried it by changing this line in the couchdb config file:
[ssl]
cacert_file = /etc/ssl/ppcjsondata.com.issuer.crt
As you suggeted, I also tried:
Let’s Encrypt Authority X3 (IdenTrust cross-signed)
I would guess what you name this file doesn't matter except it should end in crt. i just called it test.crt and changed that cacert_file to:
cacert_file = /etc/ssl/test.crt
Rebooted bitnami server and still the same problem.
This feels next to impossible.
Thanks.
Reading:
Trying to find clues in this thread:

5

http://docs.couchdb.org/en/stable/config/http.html#https-ssl-tls-options specifies an enable option:

[ssl]
enable = true
cert_file = /etc/couchdb/cert/couchdb.pem
key_file = /etc/couchdb/cert/privkey.pem

Besides enable, perhaps also try set cert_file to just the certificate (no chain), maybe CouchDB can’t deal with combined certificate format.

6

Hi,

Have you tried to place that file in an alternative location? (Maybe couchdb can’t reach that folder?)

Thank you

7

Thanks so much for your ideas. I am using couchdb version 2.2 and the latest version of the docs is different:
This is the latest version _az points out:
[ssl]
enable = true
So the docs show you don’t need enable = true:
https://docs.couchdb.org/en/2.2.0/config/http.html?highlight=ssl

I tried renaming server.crt and server.key and rebooting just to see if it complained it can’t find the file.
No, same message. This is what is killing me versus the world of programming. No way to narrow it down.
_az, maybe I have to change to .pem instead of .crt or .key. As _az points out, this is what is in the docs. I saw this:
sudo openssl rsa -des3 -in /opt/bitnami/couchdb/conf/server.key -out privkey.pem
from here:
https://docs.bitnami.com/aws/apps/trac/administration/create-ssl-certificate-apache/
Note, I don’t have apache server, it is a bitnami server.

Their support will respond Monday, but thanks to you guys I have more ideas to throw at them.

8

This is definitely wrong.
The CA cert file is NOT something you update/modify (with your cert file).

9

I thought so too, but reading CouchDB's docs, it seems like it serves a dual purpose:

The path to a file containing PEM encoded CA certificates. The CA certificates are used to build the server certificate chain, and for client authentication. Also the CAs are used in the list of acceptable client CAs passed to the client when a certificate is requested. May be omitted if there is no need to verify the client and if there are not any intermediate CAs for the server certificate:

10

This should have created a new cert and placed it somewhere in the /etc/logo folder.

11

Yes, rg305, it does

If I comment out the line:
;cacert_file = /etc/ssl/certs/ca-certificates.crt

then when I enter:
curl -vsk https://admin:password@18.214.95.156:6984
I see a different response after this section:

  • Rebuilt URL to: https://admin:MyPassword@18.214.95.156:6984/
  • Hostname was NOT found in DNS cache
  • Trying 18.214.95.156...
  • Connected to 18.214.95.156 (18.214.95.156) port 6984 (#0)
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):

So right here, instead of:

  • Unknown SSL protocol error in connection to 18.214.95.156:6984
  • Closing connection 0

Execution continues:

  • SSLv3, TLS handshake, Server hello (2):
  • SSLv3, TLS handshake, CERT (11):
  • SSLv3, TLS handshake, Server key exchange (12):
  • SSLv3, TLS handshake, Server finished (14):
  • SSLv3, TLS handshake, Client key exchange (16):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
  • Server certificate:
  •    subject: CN=ppcjsondata.com

  •    start date: 2018-12-27 17:44:01 GMT

  •    expire date: 2019-03-27 17:44:01 GMT

  •    issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3

  •    SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
  • Server auth using Basic with user 'admin'

GET / HTTP/1.1
Authorization: Basic YWRtaW46VUlWVnZsejZpMm1R
User-Agent: curl/7.38.0
Host: 18.214.95.156:6984
Accept: /

< HTTP/1.1 200 OK
< Cache-Control: must-revalidate
< Content-Length: 164
< Content-Type: application/json
< Date: Sat, 29 Dec 2018 17:35:03 GMT

  • Server CouchDB/2.2.0 (Erlang OTP/20) is not blacklisted
    < Server: CouchDB/2.2.0 (Erlang OTP/20)
    < X-Couch-Request-ID: 936bbd2ed2
    < X-CouchDB-Body-Time: 0

If I enter:
curl https://admin:password@18.214.95.156:6984
(without "-vsk") then I get:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: curl - SSL CA Certificates

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

So I need the correct "local issuer certificate" (I created the "user's" certificate) and I point to it in my configuration file with this line:
[ssl]
cacert_file = /etc/ssl/certs/ca-certificates.crt

In that /etc/ssl/certs directory, one can see loads of .pem files. I don't think it matters what extension it has, ".pem" or ".crt".

See, when cacert_file is uncommented, the program uses a default procedure and goes into the "TLS handshake" stuff without success.

When I get the correct "local issuer certificate" I will see the same kind of output except it will succeed.

Maybe time to try COMODO. One can get a free certificate for two months. If it works, I am happy to pay and stop this drain of my time.

Just in case, although I don't think I made an error in certificate creation, here is what it showed:
e[Ke]0;bitnami@ip-172-31-31-100: ~abitnami@ip-172-31-31-100:~$ sudo lego --email="admin@ppcjsondata.com" --domains="ppcjsondata.com" --domains="www.ppcjsondata.com" --path="/etc/lego" run
2018/12/29 18:18:10 [INFO] [ppcjsondata.com, www.ppcjsondata.com] acme: Obtaining bundled SAN certificate
2018/12/29 18:18:10 [INFO] [ppcjsondata.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/cCBJe3v9SQc3T7KGTY2vt6xpbyp_IGzOV9ygw_ondYQ
2018/12/29 18:18:10 [INFO] [www.ppcjsondata.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/M5D0V55ZQDI8j-yU7iSFlW-NlgJoZqZgAW3kUSZ_06E
2018/12/29 18:18:10 [INFO] [ppcjsondata.com] acme: Authorization already valid; skipping challenge
2018/12/29 18:18:10 [INFO] [www.ppcjsondata.com] acme: Authorization already valid; skipping challenge
2018/12/29 18:18:10 [INFO] [ppcjsondata.com, www.ppcjsondata.com] acme: Validations succeeded; requesting certificates
2018/12/29 18:18:12 [INFO] [ppcjsondata.com] Server responded with a certificate.
e]0;bitnami@ip-172-31-31-100: ~abitnami@ip-172-31-31-100:~$

Configured at AWS, both ppcjsondata.com and www.ppcjsondata.com
Namecheap hosts the domain name and DNS entries from AWS made correctly.
Tested: DNS Propagation Checker - Global DNS Testing Tool

12

Were the CURL tests done from the same system or from another Internet IP?

13

From my Debian Linux Cloudways server. See, I have my Laravel PHP mysql application on Cloudways and store the json data in couchdb. The Cloudways server has SSL, so of course it can only call other SSL servers. Cloudways support showed me how to get SSL in one easy step, five minutes of my time. However getting SSL in my AWS Bitnami server, 5 days and counting. Thanks for helping, rg.

My support ticket at Bitnami:


There I write about creating a csr file for certification. I would hear back on Monday but their instructions are very unclear.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.