Support Questions

Find answers, ask questions, and share your expertise

NiFi Registry HTTPS Setup Giving SSL_ERROR_BAD_CERT_ALERT

avatar
Explorer

Hello,

I am trying to setup a HTTPS on NiFi Registry and am receiving SSL_ERROR_BAD_CERT_ALERT when attempting to access the URL after loading the certificates.

The way I am setting it up is that I create a CSR, have the CA sign it (AD Domain Controller) and import that certificate into the keystore.  

 

I have generated the keystore, the truststore imported the certificates, and when I restart the NiFi Registry service the logs show no errors so I am not sure what I am doing wrong.

 

Below are some sanitized outputs of some commands I've ran to show what I could potentially have done wrong.

Curl Output:

curl --cert-type P12 --cert ./keystore.p12:Password --cacert /root/ssl/ADcerts/ad1-ca.cer -v https://nifiregistry.our.network.com:8443/nifi-registry
*   Trying 123.4.56.78:8443...
* Connected to nifiregistry.our.network.com (123.4.56.78) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /root/ssl/ADcerts/ad1-ca.cer
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=Country; ST=State; L=City; O=Org; OU=OrgUnit; CN=nifiregistry
*  start date: Jul 31 20:04:43 2023 GMT
*  expire date: Jul  6 17:37:31 2038 GMT
*  subjectAltName: host "nifiregistry.our.network.com" matched cert's "nifiregistry.our.network.com"
*  issuer: DC=com; DC=network; DC=our; CN=AD1-CA
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET /nifi-registry HTTP/1.1
> Host: nifiregistry.our.network.com:8443
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Tue, 01 Aug 2023 17:20:26 GMT
< Content-Security-Policy: frame-ancestors 'self'
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31540000
< Location: https://nifiregistry.our.network.com:8443/nifi-registry
< Content-Length: 0
<
* Connection #0 to host nifiregistry.our.network.com left intact

Keystore -V

curl --cert-type P12 --cert ./keystore.p12:Password --cacert /root/ssl/ADcerts/ad1-ca.cer -v https://nifiregistry.our.network.com:8443/nifi-registry
*   Trying 123.4.56.78:8443...
* Connected to nifiregistry.our.network.com (123.4.56.78) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /root/ssl/ADcerts/ad1-ca.cer
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=Country; ST=State; L=City; O=Org; OU=OrgUnit; CN=nifiregistry
*  start date: Jul 31 20:04:43 2023 GMT
*  expire date: Jul  6 17:37:31 2038 GMT
*  subjectAltName: host "nifiregistry.our.network.com" matched cert's "nifiregistry.our.network.com"
*  issuer: DC=com; DC=network; DC=our; CN=AD1-CA
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET /nifi-registry HTTP/1.1
> Host: nifiregistry.our.network.com:8443
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Tue, 01 Aug 2023 17:20:26 GMT
< Content-Security-Policy: frame-ancestors 'self'
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31540000
< Location: https://nifiregistry.our.network.com:8443/nifi-registry
< Content-Length: 0
<
* Connection #0 to host nifiregistry.our.network.com left intact

Nifi Properties

# web properties #
nifi.registry.web.war.directory=./lib
nifi.registry.web.http.host=
nifi.registry.web.http.port=
nifi.registry.web.https.host=123.4.56.78
nifi.registry.web.https.port=8443
nifi.registry.web.https.application.protocols=http/1.1
nifi.registry.web.jetty.working.directory=./work/jetty
nifi.registry.web.jetty.threads=200
nifi.registry.web.should.send.server.version=true

# security properties #
nifi.registry.security.keystore=./conf/keystore.p12
nifi.registry.security.keystoreType=PKCS12
nifi.registry.security.keystorePasswd=Password
nifi.registry.security.keyPasswd=Password
nifi.registry.security.truststore=./conf/truststore.p12
nifi.registry.security.truststoreType=PKCS12
nifi.registry.security.truststorePasswd=Password
nifi.registry.security.needClientAuth=
nifi.registry.security.authorizers.configuration.file=./conf/authorizers.xml
nifi.registry.security.authorizer=managed-authorizer
nifi.registry.security.identity.providers.configuration.file=./conf/identity-providers.xml
nifi.registry.security.identity.provider=ldap-identity-provider

 

1 ACCEPTED SOLUTION

avatar
Explorer

@MattWho 

I was able to get this resolved. It didn't require adding any other certificates other than my CA server certificate to the truststore for each server.  They share the same CA and so I used the same certificate in each truststore.

 

First, I am not sure why, but, NiFi did not like using port 636 for LDAPS, so I set it up to use 3269 instead and the SAN error went away.  Everything I tried prior did not resolve the error, it would give me an error that it couldn't find a SAN with my.network.com:636 along with partial LDAP result not being able to find my.network.com, which didn't make sense because all of the troubleshooting I did would come back good.  I could even resolve SSL using my key entry from my truststore.

 

Once I had it up and working after that, I had to figure out why the buckets weren't loading.  So I combed through a bunch of posts and found one that you wrote to someone having a similar issue and mentions the node needs to exist in NiFi-Registry. So, I added the node as "CN=node.hostname.com" (how I have it on the certificate) as a user account in NiFi Registry with the ability to read buckets and proxy user requests and bam buckets showed up.

 

Seems like everything is working great now.  I appreciate your help.

View solution in original post

12 REPLIES 12

avatar
Explorer

@MattWho 

I was able to get this resolved. It didn't require adding any other certificates other than my CA server certificate to the truststore for each server.  They share the same CA and so I used the same certificate in each truststore.

 

First, I am not sure why, but, NiFi did not like using port 636 for LDAPS, so I set it up to use 3269 instead and the SAN error went away.  Everything I tried prior did not resolve the error, it would give me an error that it couldn't find a SAN with my.network.com:636 along with partial LDAP result not being able to find my.network.com, which didn't make sense because all of the troubleshooting I did would come back good.  I could even resolve SSL using my key entry from my truststore.

 

Once I had it up and working after that, I had to figure out why the buckets weren't loading.  So I combed through a bunch of posts and found one that you wrote to someone having a similar issue and mentions the node needs to exist in NiFi-Registry. So, I added the node as "CN=node.hostname.com" (how I have it on the certificate) as a user account in NiFi Registry with the ability to read buckets and proxy user requests and bam buckets showed up.

 

Seems like everything is working great now.  I appreciate your help.

avatar
Master Mentor

@mslnrd 
This is likely caused by LDAP on 636 uses referrals that can your initial query can be referred to across the entire domain tree across multiple LDAP servers. So somewhere within that referral your issues arrises in the hostname verification.

Switching to the global catalog port 3269 and there are no referrals.  I can't speak to the issues within your ldaps servers causing the issue within the referrals, but makes sense why switching to the secure global catalog port resolved your issue.  

Hope this clarifies why the change in port resolved your issue.

If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.

Thank you,

Matt



avatar
Community Manager

@mslnrd Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.  Thanks.


Regards,

Diana Torres,
Community Moderator


Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.
Learn more about the Cloudera Community: