I am facing weird issue. this may very well not just be nifi(1.9.2) issue, but some other factor.
the steps i am trying to do is not new, i have done this on multiple boxes (i have 10 boxes, running with similar setup)
1) OS - unix
2) DNS is internal
3) https certificate is not self-signed, they are CA signed.
certificate generation process.
1) i generate csr on unix command line
openssl genrsa -out key.file 2048
openssl req -sha256 -new -key key.file -out out.csr
2) then i shared CSR file with 3rd party, and they got me certificate chain.
this above mentioned process was followed with all my previous setups (10 boxes). never faced this issue.
now i am facing this weird issue. (attached screenshot).
this message is very deceptive, as per internet search, nifi is rejecting my certificate/identity. but why is my identity? what certificate my connection must be presenting to nifi? and are we suppose to add everyone who is trying to come to nifi to be in nifi's trust store?
I have not face this issue with any of my previous setups :( , so cant put my finger on what must be going on.
this is not just chrome issue, i am getting similar error on all 4 big browsers.
NiFi is telling your browser that you must present a client certificate in order to authenticate to the system. This is likely because you have not configured any other authentication mechanism (LDAP, Kerberos, OpenID Connect, etc.). You can read more about these authentication mechanisms in the Apache NiFi Admin Guide.
NiFi can only be configured for username/password, OpenId Connect, or
Apache Knox at a given time. It does not support running each of these
concurrently. NiFi will require client certificates for authenticating
users over HTTPS if none of these are configured.
If you do not want to configure any of these other mechanisms, you can still authenticate using a client certificate. In order for your certificate to be accepted, it must be signed by (or be) a certificate whose public key is loaded as a trustedCertEntry in the NiFi truststore. The NiFi Toolkit Guide may help with the explicit commands you need in order to configure this.
If this isn't sufficient to solve your problem, you'll need to share more information, including your nifi.properties file (redact the sensitive values like keystore/truststore password), the output of keytool -list -v -keystore /path/to/truststore.jks, and the output of keytool -list -v -keystore /path/to/client.p12 -storetype PKCS12.
Rakesh,
I would check these things as well:
Your browser should contain a client certificate signed by the same
CA the NiFi server certificate was signed by. The browser will prompt
which certificate to use when you visit the NiFi UI.
The CA public certificate should be added to NiFi's trust store. This will allow
NiFi server to trust the client certificate in your browser.
Your client certificate DN needs to be added to the authorizers.xml file
as an Initial Admin, and you need to remove users.xml and
authorizations.xml and restart NiFi.
Related
I'm using rvest to scrape a website. I'm totally OK with other websites but this one is using another type of certificate I think. I've seen similar questions here and in github but no one could help me.
Any help is appreciated.
My script is as follows:
url <- "https://search.codal.ir/api/search/v1/q?PageNumber=1&Symbol=%D9%81%D8%B3%D8%A7&Subject=%20&CompanyState=0&LetterType=6&TracingNo=-1&LetterCode=%20&FromDate=1395/01/01&ToDate=%DB%B1%DB%B3%DB%B9%DB%B8/%DB%B0%DB%B3/%DB%B1%DB%B6&AuditorRef=-1&YearEndToDate=&Publisher=false&Mains=true&Childs=false&Audited=false&NotAudited=true&Length=-1&Consolidatable=true&NotConsolidatable=true&CompanyType=1&Category=1"
data <- fromJSON(url)[[3]]
and the error is:
"Error in open.connection(con, "rb") :
SSL certificate problem: unable to get local issuer certificate"
This is a wrongly configured server (search.codal.ir). A friendly email to their admins could probably be considered.
The problem here is that this TLS server doesn't send a complete cert chain in the handshake, which it should according to standards. More specifically, it doesn't send the intermediate certificate. This is visible by posting "search.codal.ir" into SSL Labs test page and the results are clear.
Intermediate certificates are certs that are sort of "in between" the root certificate (that exists in the CA store) and the server's own certificate.
This sometimes work better in browsers than with curl because
browsers typically cache the intermediate certs (which can be used by multiple hosts)
some browsers (like Chrome) supports features like AIA (Authority Information Access) which makes it able to download intermediate certificates on-demand. RFC 5280 has the details.
The curl error message unable to get local issuer certificate almost always means this is what happened.
Fixing it
The real and proper fix should be done by the server admins. This is a server setup problem.
Working around it
You can download the intermediate cert manually and put it in your CA store, the PEM file you tell curl (or other client) to use when verifying the peer.
The SSL Labs page says the following about the missing intermediate cert:
Certum Organization Validation CA SHA2
Fingerprint SHA256: fd02362244f31266caff005818d1004ec4eb08fb239aafaaafff47497d6005d6
Pin SHA256: 51GveKNrpJjtGpXY5QDx03s3YTQwaQic6dWBqo3zX6s=
RSA 2048 bits (e 65537) / SHA256withRSA
(I couldn't find where to download it from)
Don't do this
You can disable certificate verification completely which then will allow your program to continue. But you've then given up on all security and there are just sadness and tears going down that road. Only do that for experiments, never for production.
You can try :
library(httr)
set_config(config(ssl_verifypeer = 0L))
I am trying to set up smart card authentication for a website that I have created. Setting authentication to Windows and setting SSL to required I can get the smart card reader to pop up when they go to the web site. There are 2 credentials on the card though and only one of them is showing up as an option (the information I need is on the other credential). I asked a co worker and he said in IIS 6 there was a way to specify a location on the smart card to look for certificates. I have been researching this issue for about a week now but haven't been able to find a solution to this issue yet. Does anyone know how to do this?
IIS really only knows about certificate-based authentication, not smart-cards per se (which is really just a form of cert-based authentication). Configure your site to use certificate-based authentication, eg "Require Client Certificates" and IIS will chain the call down to Windows security, which, in turn, recognizes that among the sources for identity certificates is the smartcard reader. Depending upon your site requirements, you may also need to enable Certificate Mapping, which translates certificates into Windows account identities.
When certificates are required (or accepted) IIS will ask for a client cert in the SSL negotiation when the session is started. IIS will send a list of the Certificate Authorities it trusts to the client. The client then takes those and sees which match the list of Certificate Authorities it trusts. It then take sthe list of common entries and checks to see if it has any certs issued by a CA both sides trust. Generally, if there are none it will simply not send a cert and the request fails if the cert is required. If there is just one certificate IE will generally send that without asking the client which cert to send, but it will prompt for a PIN if required. Finally, if there are more than one certificate issued by a CA both sides trust then a dialog box will be presented to the client asking which cert to use.
In this case it sounds like perhaps the credential (certificate) you want the client to send is issued by a Certificate Authority that isn't trusted by one or both sides.
I have asp.net site on my local machine.
IIS configuration:
binding: https binding with self-signed certificate,
ssl settings: Require SSL and Require client certificates
I have installed next certificates on my machine:
CA certificate (call it 'CA Center') in Trusted Root Certification Authorities store.
Client certificate issued by 'CA Center' in Personal store
I go to site and accept server certificate. But next i get error:
HTTP Error 403.7 - Forbidden. The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
That means browser (IE) doesn't send applicable client certificates to server.
What's wrong? Should I configure something else?
I had exactly this problem, and it took me an age to figure out the cause. Turned out it was because my computer was part of a domain, and there was some sort of group policy for that domain was restricting the trusted root certificates that IIS would be willing to accept. I don't know exactly what the setting was or how to alter it, but I found I could work around it by choosing to install my certificate into the enterprise physical store using the certutil command:
certutil -addstore -v -enterprise root CertificateAuthority.cer
It sounds like the browser never prompted you to select a client certificate to send which means something is incorrect with the SSL Handshake. Try testing this with OpenSSL.
Additionally, a very common problem is having too many certificates in the Trusted Root CA folder. When the server sends the list of CAs, there is a limit to how large the list can be so if it exceeds the limit, it will truncate the remaining CA certificates. Make sure the Trusted Root CA folder doesn't have too many certificates. One way to check this is temporarily modifying the SCHANNEL in the registry editor to not send the CA List, and then re-try.
Start > Run > 'regedit' > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL >
right-click > New > DWORD > 'SendTrustedIssuerList' > Value:0
Re-install the certificates and check their effective dates. From Microsoft Support:
Download the root server certificate in a browser on the server
computer. Run the Iisca.exe command line utility that is located in
the Inetsrv directory.
Check the effective date on the client certificate and make sure that
the date and time has arrived.
Check the expiration date and make sure that the certificate has not
expired. Contact your certificate authority to see if your
certificate has expired.
Issues have been asked many times about how to handle self-signed certificates with Java and implementations are often provided. However, I'm not sure that these implementations will give me the security/trust I am looking for.
My circumstance is as follows: I have a client program connecting to our server application. Both of these we have complete control over. Our client post's a stream using https to a URL at our server, and the server responds. Currently (and this is what I'm trying to fix) the server has a self signed certificate. Java doesn't like this and FOR TESTING ONLY, we are pretty much ignoring the certificate altogether by trusting any certificate.
I have little knowledge of SSL. My boss says we can use our self-signed certificate and it will be secure as long we don't make our crypt. key public. This sounds correct to me, but a lot of posts say self-signed cert's are automatically vulnerable to man-in-the-middle attacks. Does this mean SSL sends the crypt. key along with the certificate?
Since we have control over both ends, should we just encrypt our data ourselves with a secret key, and decrypt it at the end using our key? Or is there reason to use SSL?
Instead of trusting any certificate blindly (which would make the connection vulnerable to MITM attacks), configure your Java client to trust that particular certificate. Self-signed certificates do not inherently make SSL/TLS connections vulnerable to MITM attacks, they just make their distribution and the evaluation of trust more specific to this particular deployment (i.e. you have to configure it manually).
You can do this in at least 3 ways (pick the easiest one for you, I'd suggest bullet point #2):
Import the server certificate into your client's global trust store (lib/security/cacerts in your JRE directory). This will make all applications run with this JRE trust this certificate.
Import the server certificate into another truststore (possibly a local copy of lib/security/cacerts) and make this particular application use this truststore. This can be done using the javax.net.ssl.trustStore system properties.
Make your client application use an SSLContext initialised with an X509TrustManager configured to trust that certificate: either something written manually or a trust manager coming from TrustManagerFactory initialised by loading a local keystore that contains that particular certificate (as in the previous method).
You'll find more details about all this in the JSSE Reference Guide.
(This answer to a similar question should give you the details for doing all this properly, in particular keytool -import ....)
The arguments against self signed certificates mainly apply to web-applications. Since with the current infrastructure a browser won't be able to validate your self-signed certificate.
Since you have control over the client, you can simply hardcode the certificate you expect into the client. For example you might calculate the sha1 hash of the certificate, and check if that matches the expected value. That way you don't even need to trust hundreds of CAs.
To achieve secure communication you need to first ensure your talking to the right computer. When the client first attempts to establish a secure connection, it pings the server and the server responds with its cert. At this point you MUST validate the servers cert before continuing. The cert includes a public key and signature that can be used to ensure the cert is valid. For example, in web browsers this means checking to see it's been signed by an authority listed as trusted in your browser settings, if that check fails you'll see red warnings in your browser. In your case this will mean you have manually (or in code) added the servers cert into a trust store so that it is trusted.
I have a website on our Internal network that is also accessible to the public. I have purchased and installed an SSL certificate for that public site. The site is available using both https://site.domain.com (Public) and https://site.domain.local (Internal).
The problem I am having is creating and installing a self-signed certificate for the internal "site.domain.local" so that people on our internal network do not get the security warning. I have a keystore in the root folder and also created a self-signed certificate in that keystore with no luck. The public key is working just fine. I am running Debian linux with Tomcat 7 installed and I am also using Active Directory on the network with Microsoft DNS. Any and all help would be greatly appreciated. If you need more details, please ask.
Not sure I fully understand your set-up, but you could front your Tomcat with Apache, install the cert on the Apache instance and then do a Reverse-Proxy (plain http) to your Tomcat instance. People would access the Apache instance which would handle the SSL connection.
One way would be to add the CA certificate in every client certificate trusted store (which is not convenient) : the client click on the certificate warning message and install/trust the self signed x509 CA certificate. If this doesn't work, there is a problem with the certificate (though most openssl generated stuff .CER/.CRT/.P12/.PFX will install with no problem under recent windows).
If one client accepts the self-signed certificate with manual setup, you can try to install these certificates with Active Directory ; basically you add trusted CA cert within your AD, and client automagically synchronize (nb: mostly on login) : See there for a hint about setting thing up with AD : http://support.microsoft.com/kb/295663/en-us (You may try this or dig in that direction : with AD, you never know).
Another possibility would be to set up your internal DNS to point site.domain.com to the local web site address (the easy way). You can test this setup with you /etc/hosts file on linux/unix flavours (or system32/drivers/etc/hosts on windows flavours)
If your certificate is for site.domain.com and users are going to site.domain.local and getting that cert, then clearly there is a name mismatch and the browser will always warn you.
You either need to :
get the cert regenerated with BOTH names
get a cert for just the internal site
mangle DNS so that when your internal users go to site.domain.com
they get the IP address of site.domain.local.