1

I'm trying to enable TLS on a Nexus Container, while the browser shows HTTPS, if you use curl against the url, you'll get errors. I feel that I'm missing something in this process, so I'll go step-by-step. I'm not TLS expert, so please bear with me.

I'm using ketyool on a Nexus3:3.30.0 container to generate .jks and .pem file. Container is hosted on a RHEL8 workstation.

The .jks and .pem files are generated under /ops/sonatype/nexus/etc/ssl and I use the following commands:

keytool -genkeypair -alias <alias-goes-here> -keyalg RSA -keysize 2048 -validity 365 -keystore <name of file here>.jks 

I answer the following questions:

first and last name - name of internal CA here
org unit - name of org unit here 
org - name of company here
city - name of city here
state - name of state here 
country code - name of country here 

I validate the .jks file with the following command: keytool -list -v -keystore <name of jks file here.jks

I generate the .pem file with the following command:

keytool -certreq -alias <alias here> -file <name of pem here>.pem -keystore <name of jks file here>.jks ext 'SAN=DNS entries here'

The .pem file is then sent to an internal Microsoft Active Directory Certificate Services, to submit a certificate request. I paste the output into the Save Request Field, From Certificate Template, from the drop down Web Server and click submit.

I get a .p7b file, from there I go thru a process of extracting the root, intermediate and server certificate, along with giving them a meaningful names, for example root-server.cer, so it makes it easier to keep track of what cert is what.

I move these .cer files back to to the container and import them in the following order: root, intermediate and then server. Using the following commands:

keytool -importcert -file root-cert.cer -keystore <name of jks file>.jks -alias root-cert

keytool -importcert -file intermediate-cert.cer -keystore <name of jks file>.jks -alias intermediate-cert

keytool -importcert -file server-cert.cer -keystore <name of jks file>.jks -alias server-cert

I confirm that all certs have been imported into the keystore with the following command: keytool -list -v -keystore <name of jks file>.jks

I go thru a few configuration of the Nexus container itself to prepare it for HTTPS. Once done, I restart the container and refresh the browser and the UI comes back up as HTTPS. However the Icon Lock in the browser shows Connection is Not Secure.

Upon further investigation with command line tools like curl and openssl, I've determine that something has gone wrong.

This is the output of the curl command I use against the container:

[user_a@host_a tmp]$ curl -l -v https://10.88.0.214:8082
* Rebuilt URL to: https://10.88.0.214:8082/
*   Trying 10.88.0.214...
* TCP_NODELAY set
* Connected to 10.88.0.214 (10.88.0.214) port 8082 (#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.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Any of the openssl commands that I used, for example:

openssl s_client --connect <ip address here:port number here> --showcerts 

Any of the output shows

Verification error: self signed certificate 

Why is this showing this? The certificate is not self-signed as it went to an internal CA, which lives on a Windows server. Or should this even matter?

Are there are other commands that I can run to help troubleshoot, to get more info?

Is there something that I need to do since I'm moving from a Linux based container to an internal Windows CA?

Am I missing any steps in this process?

thanks in advance

4
  • 1
    The internal CA is likely explicitly made trusted by the browser. But openssl does not use the same trust store as the browser, so it will not trust this CA. Hence the verification problem: TLS alert, unknown CA (560) Nov 12, 2021 at 20:25
  • Does this depend on the browser (Microsoft's Edge, Google Chrome or Mozilla Firefox)? As I've seen online that different browsers have different errors. How can I tell what trust store openssl is using along with a browser? Nov 13, 2021 at 17:13
  • Which trust store is used depends on the specific client, OS and possibly client settings. Chrome can use the system trust store on some systems but uses its own on others (like Linux). Firefox usually uses its own. openssl depend on compilation settings, see openssl version -a. curl depends based on the TLS backend it uses (it supports a lot) ... You can check on Linux with strace -e stat openssl .. where it looks for files including where it looks for CA certificates. Nov 13, 2021 at 18:25
  • Thanks for the pointers. As someone learning TLS on the fly, is there a good resource online that could help with the basic fundamentals? I feel like I have major missing gaps in my knowledge. Nov 14, 2021 at 14:34

1 Answer 1

2

You say you did

keytool -genkeypair -alias <alias-goes-here> -keyalg RSA -keysize 2048 -validity 365 -keystore <name of file here>.jks 
keytool -certreq -alias <alias here> -file <name of pem here>.pem -keystore <name of jks file here>.jks ext 'SAN=DNS entries here'

and after getting the CA-issued cert

keytool -importcert -file server-cert.cer -keystore <name of jks file>.jks -alias server-cert

I can't tell if <alias here> is server-cert or not. If they are different that's wrong. You must import (at least) your 'end-entity'=server cert to the same alias/entry in the same keystore that was used for -genkeypair and -certreq. The test is whether keytool responds Certificate reply was installed (correct) or Certificate was added (wrong). (If it says the key doesn't match, that's also wrong.)

I said 'at least' because you don't actually need to split apart the p7b and import the certs separately; keytool -importcert for a valid reply to a PrivateKeyEntry only can read the entire chain from a p7b in one operation. OTOH if you enjoy spending your time splitting them apart, that works also, as long as all the CA certs are imported to different entries (not the PrivateKeyEntry) and the EE/server cert is imported last and to the same entry (the PrivateKeyEntry).

In short, you must use the privateKey entry by specifying the keystore file containing it and the alias of it.

If you didn't do that (or until you do that), the PrivateKeyEntry in the JKS still contains the dummy self-signed cert created by -genkeypair. Since you put the CA-issued cert somewhere else and not in the PrivateKeyEntry, it isn't used; the server continues to use the dummy self-signed cert, which both the browser and curl correctly consider invalid.

Crossdupe https://stackoverflow.com/questions/31948701/import-ca-signed-certificates-to-jks -- and I'm certain I've seen others but couldn't find them then and still can't. In any case that SO Q is probably considered offtopic now, so it doesn't hurt to have it here where it is ontopic.

1
  • Felt like I was reading a brain dump, however after reading this post a number of times, yes, you are correct. I DID NOT have matching aliases when generating the .jks file and the .pem file. Once I corrected this, along with using the same alias used when creating the .pem and .jks file and when importing the server cert into the .jks file, I was able to get TLS working. Nov 19, 2021 at 18:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .