I am trying to verify the cipher suites that are being offered by my web server is restricted to only secure ciphers.
There are several different sites running on the server (using different web servers).
How can I specify the full URL including the path to the site I'm testing?
echo -n | openssl s_client -connect 10.10.10.63:443/sites/mySiteA
getaddrinfo: Servname not supported for ai_socktype
connect:errno=0
Related
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.
I am want to use QUIC protocol to send my own data (lets say a video). I have already done the following setup,
1- download and compiled this https://github.com/google/proto-quic
2- I have also set up the toy example. https://www.chromium.org/quic/playing-with-quic
Issue: I can only send this www.example.com page, How I can send my own data over the quic in this setup.
I would recommend you to use the Caddy project on the server side.
An alternative can be GoQuic.
Both servers should be configured to provide your own web page via QUIC (which might also contain video). QUIC works only if the connection is secure, so a certificate for a valid domain should be generated. In the example here the certificate is generated for the domain www.example.org. If you want to generate a valid certificate for https://localhost the script that generates the certificate has to be updated accordingly.
On the client side use the last version of Google Chrome. Run Chrome from the command line as follows:
google-chrome \
--user-data-dir=/tmp/chrome-profile \
--no-proxy-server \
--enable-quic \
--origin-to-force-quic-on=localhost:443 \
--host-resolver-rules='MAP localhost.org:443' \
https://localhost
When my ASP.NET website is running on a windows 7 box, it can connect (programmatically as a "client") to an SSL-encrypted service ("server") on another windows 7 machine just fine.
But if my website is on the production box (windows server 2003), the service's windows log shows:
An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.
(service is using a self-signed cert created by makecert.exe, but I can't see how to make makecert allow more cipher suites... or do I install something on the 2003 boxes...? This: https://serverfault.com/questions/166750 doesn't work for me because I am not using a CSR)
The solution was to generate my certificate again, this time forcing RSA and SHA1 (though SHA1 should be the default anyway). For some reason Win Server 2k3 couldn't or wouldn't use the right ciphers with a default makecert certificate. Here is the command line that worked for me:
makecert -pe -r -ss my -sr localMachine -n "CN=domainnameoripaddressgoeshere.com" -e 01/01/2098 -a sha1 -eku 1.3.6.1.5.5.7.3.1 -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
For details see http://mgowen.com/2013/06/19/cipher-suites-issue/ and http://msdn.microsoft.com/en-us/library/bfsktky3(v=vs.110).aspx .
If anyone finding this does want to know about cipher suites though, here's some stuff I found along the way that may help you:
You can add two RSA cipher suites to windows server 2003 using this hotfix: http://support.microsoft.com/kb/948963
You can see which ciphers are supported in regedit (windows registry editor) under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers
You can use IIS Crypto (a free cipher config app, https://www.nartac.com/Products/IISCrypto/) to view and enable/disable ciphers (including those hotfix ciphers above).
I am installing spnego on a java app server that will authenticate users against Active Directory. I've followed all of the directions closely, and the AD Preauth account has the java app server FQDN in the servicePrincipalName attribute. We already have another java app server with spnego installed that works correctly (I did not do that install and they are no longer here).
I've developed a simple java EE 6 web app to test that spnego is working correctly (jsp page with request.getRemoteUser() ). I correctly get my username response when I run this app on the existing server. When I run it on the new server I'm setting up, I get the following error:
java.lang.UnsupportedOperationException: NTLM specified. Downgraded to Basic Auth (and/or SSL) but downgrade not supported.
Using Fiddler to inspect the sessions, The Authorization: Negotiate token request to the correctly working server is a huge string (the Kerberos token I believe?). The Authorization: Negotiate token request to the non-working server is only 56 characters long (so, NTLM token?). When the server receives that NTLM token, I believe that's when the error is thrown.
I've inspected the responses from the earlier negotiation sessions, but can't find where the server is asking for Kerberos vs. NTLM tokens. How does the browser determine what do send?
Additional details: Java App Server machine: Windows 2008 R2, Java 1.7, Glassfish 3.1.2.2
Client Machine: Windows 7 Enterprise, IE8 on a standard corporate windows domain
Thanks.
The servicePrincipalName isn't just the FQDN; it needs to include the service as well. Like: HTTP/MYSERVER.MYDOMAIN.COM.
The address you're visiting in your web browser must match that FQDN. In fact, you can add any IP in your OS HOSTS file to match this FQDN and it should work OK (even if the IP is 127.0.0.1 and you want to test SPNEGO-Kerberos locally)
From the command-prompt of the browser OS, run: klist get HTTP/MYSERVER.MYDOMAIN.COM, and verify you get a ticket. My guess is that this will fail.
Assuming the third point fails, then you have a larger problem with Kerberos configuration (not your browser/webserver), either on your client OS or your KDC.
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.