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 <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 <https://andybank.com/>, my keystore would contain the certificate that identifies “CN=andyapp.com <http://andyapp.com/>” and possesses the private key used to sign content and prove that I am "andyapp.com <http://andyapp.com/>", while my truststore must either contain a certificate entry containing the public key for “andybank.com <http://andybank.com/>” or a certificate entry for the certificate authority (CA) that signed the “andybank.com <http://andybank.com/>” certificate (let’s pretend it was Verisign), and thus allows my application to validate the “certificate chain” of endpoint “andybank.com <http://andybank.com/>” to “verisign.com <http://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 <http://server.com/>” but the site is not actually running on “server.com <http://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/ <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 <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]] > 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 >> 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 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
