CSR Based Certificate Request leads to a bad/untrusted Certificate?

Greetings -

I am trying to leverage LetsEncrypt for machine certificates to secure an instance of Elasticsearch and Kibana. So, none of the usual web servers are in play here.

I followed the steps outlined in the accepted answer on this Stackoverflow post but the certificate returned by the LetsEncrypt CA isn’t being accepted. My first attempt results in something that explicitly said "This certificate is not trusted." when I tried to add it to a keystore. The second attempt did not … but Elasticsearch responded to both in exactly the same manner… “certificate_unknown”

Environment:
Debian-8 Jessie
Elasticsearch, Kibana, Shield 2.3.x

Steps/Commands Executed and corresponding Output:

0) Get latest letsencrypt version:
git clone https://github.com/letsencrypt/letsencrypt cd ~/letsencrypt ./letsencrypt-auto --help

1) Get the root certificate from https://letsencrypt.org/certificates/ and store it at /etc/letsencrypt
cd /etc/letsencrypt
wget https://letsencrypt.org/certs/isrgrootx1.pem isrgrootx1.pem

2) Create a node keystore and import the CA cert using Java Keytool
cd /etc/elasticsearch/shield
sudo keytool -keystore hostname.jks -importcert -file /etc/letsencrypt/isrgrootx1.pem -alias letsencrypt-root-cert

And specify a password for the keystore and confirm:

Enter keystore password: Re-enter new password:

Which results in this:
Owner: CN=ISRG Root X1, O=Internet Security Research Group, C=US
Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US
Serial number: 8210cfb0d240e3594463e0bb63828b00
Valid from: Thu Jun 04 11:04:38 UTC 2015 until: Mon Jun 04 11:04:38 UTC 2035
Certificate fingerprints:
MD5: 0C:D2:F9:E0:DA:17:73:E9:ED:86:4D:A5:E3:70:E7:4E
SHA1: CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8
SHA256: 96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 79 B4 59 E6 7B B6 E5 E4 01 73 80 08 88 C8 1A 58 y.Y…s…X
0010: F6 E9 9B 6E …n
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore

3) Generate a private key for the node to initiate a certificate request:
sudo -genkey -alias hostname -keystore hostname.jks -keyalg RSA -keysize 2048 -validity 712 -ext san=dns:sub.domain.com Enter keystore password: What is your first and last name? [Unknown]: sub.domain.com What is the name of your organizational unit? [Unknown]: sub.domain.com What is the name of your organization? [Unknown]: Company Name What is the name of your City or Locality? [Unknown]: City Name What is the name of your State or Province? [Unknown]: State Name What is the two-letter country code for this unit? [Unknown]: US Is CN=sub.domain.com, OU=sub.domain.com, O=Company Name, L=City Name, ST=State Name, C=US correct? [no]: yes Enter key password for <hostname> (RETURN if same as keystore password):
4. Create a certificate signing request (CSR):
sudo keytool -certreq -alias hostname -keystore hostname.jks -file hostname.csr -keyalg rsa -ext san=dns:sub.domain.com Enter keystore password: sudo openssl req -outform der -in hostname.csr -out hostname.der sudo openssl req -inform der -in hostname.der -text -noout
which results in this output:
Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=State Name, L=City Name, O=Company Name, OU=sub.domain.com, CN=sub.domain.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: **... large hex output ...** Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:sub.domain.com X509v3 Subject Key Identifier: 0E:A0:CE:9B:30:96:31:53:E8:73:DF:21:CE:3C:43:2B:0B:B0:F5:7F Signature Algorithm: sha256WithRSAEncryption **... large hex output ...**
5. Send the certificate request to your CA (LetsEncrypt) to receive a signed certificate:
cd ~/letsencrypt ./letsencrypt-auto auth --csr /etc/elasticsearch/shield/hostname.der
`Requesting root privileges to run certbot…
/home/myusername/.local/share/letsencrypt/bin/letsencrypt auth --csr /etc/elasticsearch/shield/hostname.der
IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at
    /home/myusername/letsencrypt/0003_chain.pem. Your cert will expire on
    2016-11-08. To obtain a new or tweaked version of this certificate
    in the future, simply run letsencrypt-auto again. To
    non-interactively renew all of your certificates, run
    "letsencrypt-auto renew"
  • If you like Certbot, please consider supporting our work by:
    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le
    **6. Add this certificate to the keystore:**sudo keytool -keystore hostname.jks -importcert -file /home/myusername/letsencrypt/0003_chain.pem -alias hostname
    which prints out the certificate contents and promptsTrust this certificate? [no]: yes
    Certificate was added to keystore
    `
  1. Use this keystore in the Elasticsearch config
    sudo vi /etc/elasticsearch/elasticsearch.yml

shield.ssl.keystore.path: /etc/elasticsearch/shield/hostname.jks shield.ssl.keystore.password: pass shield.transport.ssl: true shield.http.ssl: true discovery.zen.ping_timeout: 30s

which results in the following error:
[2016-08-10 22:44:53,735][ERROR][shield.transport.netty ] [elastic-nodename] SSL/TLS handshake failed, closing channel: General SSLEngine problem
[2016-08-10 22:44:53,740][WARN ][shield.transport.netty ] [elastic-nodename] exception caught on transport layer [[id: 0x8bccfea3, /127.0.0.1:50796 => /127.0.0.1:9300]
], closing connection
javax.net.ssl.SSLException: Received fatal alert: certificate_unknown

I realize that this isn’t purely a LetsEncrypt interaction but would really appreciate if anyone can help me understand what exactly I am doing wrong AND/OR confirm what I am doing right.

Thanks very much!
Rajiv

Currently, the Let’s Encrypt certificates are signed by the Let’s Encrypt Authority X3, cross-signed by IdenTrust (DST Root CA X3), intermediate certificate.

The ISRG Root X1 is only just been trusted by Mozilla. All other root certificate stores aren’t trusting ISRG Root X1 as of yet. And there currently isn’t a signed intermediate by this root.

So possible reasons why it isn’t working: you’ve added the wrong root certificate or you should also add the intermediate certificate.

2 Likes

Thanks very much. That was indeed the problem!

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