Is your NiFi tied into an LDAP server that can provide user authentication? If not use each user will need to have thirty own certificate that can be used to authenticate them. My guess is that you do not have an LDAP and you also do not have a user certificate loaded into your browser. I would recommend in this case that you create both a certificate for your self that can be loaded in to the briefest for user authentication purposes. In order for 2-way authentication to work your cert or the CA (preferred) must also be included in the trust store your NiFi is configured to use. It may be easier to just use the site tinycert.org to create your own CA and also create a new server cert and user cert(s) signed by that CA. The truststore would then just need to include the cert for your CA. The keystore would contain the server cert. Your user cert also signed by that CA would get loaded into your browser as a user certificate. You will need to manually create the first user in your authorized-users.XML file as well with at least the admin role. On Feb 8, 2016 7:26 PM, "Andy LoPresto" <[email protected]> wrote:
> Hi Alex, > > The “choose a certificate” option allows the user/browser to provide a > certificate identifying the client. This is only required if the server > (NiFi) is using client certificates as the sole authentication mechanism. > NiFi can be configured to provide HTTPS (TLS) connections to the web > interface and API without requiring client certificates. > > I have a couple requests for more information that should help us diagnose > this issue. Forgive me, as I am not as familiar with these processes on a > Windows machine. > > First, can you try connecting to the server using the OpenSSL command line > tool? This can be accomplished using the OpenSSL tools [1][2]: > > $ openssl s_client -connect <host:port> -debug > > In your case, you would provide 127.0.0.1:2222, or your actual IP and the > port, as the parameter for the -connect flag. > > This output will help you determine what the response from the NiFi server > is when an HTTPS connection attempt and handshake negotiation is attempted > by the browser. I am in the process of working on another user issue to > detect negotiation issues, and I am hoping to make some tools available > which will ease this debugging in future releases. > > I also notice that in your config in nifi.properties, your keystore and > truststore point to the same file. This is not necessarily a problem, but I > want to double check that you are aware of the dual role in this situation. > A keystore contains the certificates and keys that you use to identify your > resource/endpoint in incoming/outgoing connections. The truststore provides > a repository of public keys and certificates that are deemed “trustworthy” > when provided by the other endpoint in a connection. For example, if I run > a web application called “AndyApp” hosted at https://andyapp.com, and my > application needs to make secure calls to a merchant services company or > bank in order to process financial actions, hosted at https://andybank.com, > my keystore would contain the certificate that identifies “CN=andyapp.com” > and possesses the private key used to sign content and prove that I am > "andyapp.com", while my truststore must either contain a certificate > entry containing the public key for “andybank.com” or a certificate entry > for the certificate authority (CA) that signed the “andybank.com” > certificate (let’s pretend it was Verisign), and thus allows my application > to validate the “certificate chain” of endpoint “andybank.com” to “ > verisign.com” and then say, “Yes, because I trust Verisign, I trust > anything signed by Verisign, and this is signed by Verisign, so I trust it.” > > In this case, you can verify the trust of a specific certificate by the > output from OpenSSL above (essentially any error code in the 20-29 range > indicates an issue with the certificate validation process), or more > generically by running “$ openssl verify certificate.pem” [3] > > One generic issue is that the server certificate DN needs to match the > host which is providing the certificate. This hostname evaluation underpins > the entire trust model of SSL/TLS. If the DN contains a CN identifying “ > server.com” but the site is not actually running on “server.com”, > different browsers/clients will respond with different error messages. Some > may transparently accept this hostname mismatch (this is very bad), others > will warn with varying descriptions, and still others will abort the > connection procedure entirely. I am not familiar with how IE treats this, > but I believe on a Server version of Windows, it has special access > policies called “Enhanced Security Configuration” [4] which apply very > restrictive rules to browser access on that machine. > > I can suggest a couple steps to take without knowing the actual issue you > are encountering, but will probably be able to offer better advice after > seeing the output of the openssl command referenced above. > > * Add additional hostnames such as localhost, 127.0.0.1, and the actual IP > address of the host machine to the SubjectAlternateNames section of the > self-issued certificate you are using [5][6] > * Sign the certificate with your CA or import the self-signed certificate > into your local truststore [7] > * Add the domain for the locally-hosted site to the Trusted Zone in > Internet Explorer [8] > > [1] https://www.openssl.org/community/binaries.html > [2] > http://blog.didierstevens.com/2015/03/30/howto-make-your-own-cert-with-openssl-on-windows/ > [3] https://www.openssl.org/docs/manmaster/apps/verify.html > [4] https://technet.microsoft.com/en-us/library/dd883248(v=ws.10).aspx > [5] http://wiki.cacert.org/FAQ/subjectAltName > [6] http://stackoverflow.com/a/21494483/70465 > [7] http://stackoverflow.com/a/2200859/70465 > [8] > http://windows.microsoft.com/en-us/windows/change-internet-explorer-security-settings#1TC=windows-7 > > Andy LoPresto > [email protected] > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Feb 8, 2016, at 1:10 PM, Cruz, Alexandre <[email protected]> > wrote: > > I tried a fresh Private IE and I don’t get "Choose a certificate" option. > > This is what I get. > > This page can't be displayed > > •Make sure the web address is correct. > •Look for the page with your search engine. > •Refresh the page in a few minutes. > > Thanks, > > Alex > > -----Original Message----- > From: James Wing [mailto:[email protected] <[email protected]>] > Sent: Monday, February 08, 2016 3:02 PM > To: [email protected] > Subject: Re: NIFI on Windows Server 2008 R2 > > Did you try it with a fresh Private/Incognito window? Do you get to the > "Choose a certificate" step, or just nothing? > > On Mon, Feb 8, 2016 at 12:49 PM, Cruz, Alexandre < > [email protected]> wrote: > > Team, > > I wonder if someone has NIFI running on Windows Server 2008 R2. > In my environment is works until I try to enable HTTPS, once it is set for > HTTPS, I can't open NIFI on the browser anymore: > > I know that the NIFI is running: > > 2016-02-08 07:11:31,528 INFO [main] org.eclipse.jetty.server.Server > Started @41971ms > 2016-02-08 07:11:32,464 INFO [main] org.apache.nifi.web.server.JettyServer > NiFi has started. The UI is available at the following URLs: > 2016-02-08 07:11:32,464 INFO [main] org.apache.nifi.web.server.JettyServer > https://MyIP:2222/nifi <https://myip:2222/nifi> > 2016-02-08 07:11:32,464 INFO [main] org.apache.nifi.BootstrapListener > Successfully initiated communication with Bootstrap > 2016-02-08 07:11:32,464 INFO [main] org.apache.nifi.NiFi Controller > initialization took 15595493981 nanoseconds. > > Nifi.Properties: > > # web properties # > nifi.web.war.directory=./lib > nifi.web.http.host= > nifi.web.http.port= > nifi.web.https.host=MyIP > nifi.web.https.port=2222 > nifi.web.jetty.working.directory=./work/jetty > nifi.web.jetty.threads=200 > > # security properties # > nifi.sensitive.props.key=somekeyvalue > nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL > nifi.sensitive.props.provider=BC > > nifi.security.keystore=D:/Installs/nifi-0.4.1/conf/server.jks > nifi.security.keystoreType=JKS > nifi.security.keystorePasswd=###### > nifi.security.keyPasswd=###### > nifi.security.truststore=D:/Installs/nifi-0.4.1/conf/server.jks > nifi.security.truststoreType=JKS > nifi.security.truststorePasswd=###### > nifi.security.needClientAuth=true > nifi.security.user.credential.cache.duration=24 hours > nifi.security.user.authority.provider=file-provider > nifi.security.user.login.identity.provider= > nifi.security.support.new.account.requests= > # Valid Authorities include: > ROLE_MONITOR,ROLE_DFM,ROLE_ADMIN,ROLE_PROVENANCE,ROLE_NIFI > nifi.security.anonymous.authorities= > nifi.security.ocsp.responder.url= > nifi.security.ocsp.responder.certificate= > > I created a self-signed certificate: > > keytool -genkey -alias server -keyalg RSA -keysize 2048 -keystore > server.jks -dname "CN=server.com,OU=12, O=ORG, L=City, ST=Texas, C=US" > keytool -export -alias server -keystore server.jks -rfc -file server.cer > > > > > > Any help is highly appreciated, please let me know if you need more > details about it. > > > Thanks, > > > Alex > > >
