@frank chen
The CN for your certificate should match the FQDN of the server where you installed NiFi. Using localhost in a certificate is never a good idea from a security standpoint. Alternatively you can create a certificate that uses SAN names. These SAN names should be DNS resolvable hostnames (With a SAN entry that matches the FQDN of the server the CN does not then need to contain the FQDN. While it is possible to add a security exception in your browser for this bad server cert, you will not be able to do this should you standup a NiFi cluster where the nodes talk securely to one another.
I suggest using the toolkit to generate a certificate that uses the servers FQDN as both its CN and as a Subject Alternative Name (SAN) DNS entry.
That aside, where did you get your user certificate that is being used to authenticate you as a user to access NiFi? You can use the tls-tookit to create a user certificate as well which you will need to load in your browser. Alternatively, you could configure NiFi to use an external LDAP server or kerberos for user authentication.
When you access a secured NiFi instance/cluster URL, the server looks for a valid user certificate it can trust in the request. If no client cert is presented to authenticate with, NiFi will check to see fi any other authentication method has been configured in NiFi. If none have been configured the connection is closed.
So your issue is one of the following:
1. Your browser is not have a client (user) certificate loaded to pass to NIFi for authentication.
2. You have a user certificate but it is not trusted by your NiFi instance/cluster. The entries in the NiFi truststore.jks are used to trust the client certificates presented. The keystore typically includes a bunch Certificate authority (CA) trustedCertEntries. It may also contain the public keys of self-signed certificates as trustedCertEntries.
If you found this answer addressed your question, please don't forget to mark it "accepted".
Thank you,
Matt
