Use LE certificate/key for TLS localhost.crt and localhost.key

Help
1

I have been using LetsEncrypt certificates for some time, and they've been working fine for the sites that I host under Apache.

I need to create a very lightweight https server in Java, and it appears to be failing during the SSL negotiation. I cloned this system (hoyo.zeetix.com) from its counterpart (byron.zeetix.com). Each is a robust AWS EC2 instance running Linux.

I'm pretty sure that at least part of the problem is revealed in the curl output below. Based on my ssl.conf, it appears that the negotiation is looking in /etc/pki/tls/certs, for something called ca-bundle.crt.

I have not knowingly changed anything in /etc/pki/tls after cloning this instance from byron.zeetix.com. I used certbot to delete the certs for byron.zeetix.com and created new certs for hoyo.zeetix.com. Those all live in the regular place (/etc/letsencrypt/).

I've noticed that two files are (still) identical between hoyo and byron:

  • /etc/pki/tls/certs/localhost.crt
  • /etc/pki/tls/private/localhost.key

Do I need to do something in /etc/pki/tls so that I can connect to the new https server I'm trying spin up?

I invite the guidance of this community.

My domain is: hoyo.zeetix.com

I ran this command: curl -vvv https://tms.hoyo.zeetix.com:7899/test

It produced this output:

[tms@hoyo ~]$ curl -vvv https://tms.hoyo.zeetix.com:7899/test
*   Trying 172.30.2.59...
* TCP_NODELAY set
* Connected to tms.hoyo.zeetix.com (172.30.2.59) port 7899 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to tms.hoyo.zeetix.com:7899 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to tms.hoyo.zeetix.com:7899

My web server is (include version): NA

The operating system my web server runs on is (include version): Rocky Linux (CentOS 8)

My hosting provider, if applicable, is: NA

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.5.0

2

That looks like a networking error to me, unrelated to TLS. Is TCP port 7899 open on your instance firewall and the EC2 Security Group?

3

That looks like a networking error to me, unrelated to TLS. Is TCP port 7899 open on your instance firewall and the EC2 Security Group?

Indeed, it might be.

Yes, port 7899 is open on the instance firewall. It probably isn't in the Security Group, but since I'm doing the curl from the same system (and since I have the host name bound to the private IP address of the instance), I don't think that matters.

The same simple server works fine on the same port when using http instead of https. In the server code, this is the difference between HttpServer and HttpsServer, both part of the same standard Java 1.8 distribution.

I could well be screwing up the setup and configuration of HttpsServer (in Java). I'm using the default SSLContext, so perhaps that's an issue.

I appreciate your attention!

4

For what it's worth, below is curl -vvv results from a successful call to a different port on the same system. That port is managed by a node js service (a node express service, to be specific).

The problem seems to be the way that the Java server handles the negotiation. This is done by javax.net.ssl.SSLContext (provided by Oracle). I guess the resolution of this is outside the scope of LetsEncrypt.

[tms@hoyo curl_results]$ curl -vvv https://hoyo.zeetix.com:7103/mysql/v1/isNovelEmail?email=foo%40bard.com
*   Trying 172.30.2.59...
* TCP_NODELAY set
* Connected to hoyo.zeetix.com (172.30.2.59) port 7103 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=covid.tms.hoyo.zeetix.com
*  start date: Apr  4 23:15:14 2023 GMT
*  expire date: Jul  3 23:15:13 2023 GMT
*  subjectAltName: host "hoyo.zeetix.com" matched cert's "hoyo.zeetix.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET /mysql/v1/isNovelEmail?email=foo%40bard.com HTTP/1.1
> Host: hoyo.zeetix.com:7103
> User-Agent: curl/7.61.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
< Content-Length: 4
< ETag: W/"4-X/5TO4MPCKAyY0ipFgr6/IraRNs"
< Date: Sat, 08 Apr 2023 15:51:33 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host hoyo.zeetix.com left intact
true
5

Definitely :frowning:

6

I did eventually solve this and the result had nothing to do with LetsEncrypt.

The problem was in the incredibly tortuous, verbose, and virtually undocumented behavior of the several Java packages involved in moving from HttpServer to HttpsServer. Once I discovered (and reverse-engineered) the missing incantations (involving trust managers, key managers, conversion from .pem to some internal Java special snowflake and so on), all was well.

I appreciate the attention and patience of this community.