I've got problems connecting secure (SSL) to an IBM LDAP server using an openLDAP client.
A connection like the following, which is not using SSL works fine:
ldapsearch -h <LDAP server host name> -D <bind dn> -w ? -b <base dn> <filter>
But when I add the -Z option to use a secure LDAP connection (SSL) like shown in the following ldapsearch an error occours:
ldapsearch -h <LDAP server host name> -Z -D <bind dn> -w ? -b <base dn> <filter>
The error says:
ldap_simple_bind: Can't contact LDAP server
Attempted communication over SSL.
The extended error is 116.
Here I found out that I have to add ssl start_tls to the clients configuration file (ldap.conf) to enable SSL in openLDAP: http://www.openldap.org/faq/data/cache/185.html
After reading the description above I'm not sure if the author is dealing with an openLDAP client and an openLDAP server and if this is the only change that have to be made to make the connection work.
Does anybody here know if it is possible to connect from an openLDAP client to an IBM LDAP server using an SSL connection?
Does anybody have experience with this topic?
Thanks a lot!
As far as I know, OpenSSL no longer provides CA signer certificates in its trust store (i.e., CA cert file). Therefore, you will have to configure OpenLDAP's ldapsearch through the file .ldaprc or ldap.conf to specify the location of the trust store that has the signer certificates for your LDAP server. Something like this:
TLS_CACERT /usr/ssl/certs/my.ldapserver.certs.pem
# TLS_CACERTDIR /usr/ssl/certs/
TLS_REQCERT never|allow||try|demand|hard
See
http://www.openldap.org/software/man.cgi?query=ldap.conf&format=html
http://www.openldap.org/faq/data/cache/185.html
for more details.
IBM's website has a discussion of this error.
A number of possibilities, mostly server side, about keys not being in the keystore, expired, or not using port 636. So you can look at this and see if it helps you.
Related
I need to get information about a VM using curl with REST calls. I have this information where 1701 is the VM ID
GET /api/v1/vms/1701 HTTP/1.1
Host: vmlam.ral.sf.com
Authorization: Token token=4210
I tried this in cygwin but it did not work
c:/curl-7.69.0-win64-mingw/bin/curl -X GET -d '{Authorization: Token token=4210}' 'https:/vmlam.ral.sf.com//api/v1/vms/1701'
curl: (60) SSL certificate problem: unable to get local issuer
certificate More details here: curl.haxx.se/docs/sslcerts.html curl
failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this
situation and how to fix it, please visit the web page mentioned
above.
That seems like a certificate issue, you can skip the check with the option -k (or --insecure)
From curl documentation (man curl):
-k, --insecure
(TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even for server connections other‐
wise considered insecure.
The server connection is verified by making sure the server's certificate contains the right name and verifies successfully using the cert store.
See this online resource for further details:
https://curl.haxx.se/docs/sslcerts.html
See also --proxy-insecure and --cacert.
I have a Sails.js Application enabled with SSL mode with key,cert,ca information provided in local.js.
I am able to start the server and able to communicate using certificates successfully.
By default hostname provided in the request is verified against the hostname matching the server certificate CN.
For example if server certificate CN is example.net and curl request is made with proper certificates and hostname is provided as example.net(like curl --cacert path_to_cacert --cert path_to_client_cert --key path_to_client_key https://example.net:port_number/) the communication is success and expected response is received.
If the server has DNS FQDN different from server certificate CN then curl command with DNS FQDN fails with error "subjectAltName does not match SERVER_CN"
Example: curl --cacert path_to_cacert --cert path_to_client_cert --key path_to_client_key https://newexample.org:port_number/
(newexample.org in this case resolves to same server to which example.net is configured)
I would like to know if there is a way to skip this hostname verification by default?
For example, I should be able to get expected response with hostname other than example.net also in above case.
I have tried adding "checkServerIdentity:false" in ssl config to see hostname verification is skipped.But that didn't help.
please let me know if we have a way to skip hostname verification in sails.js similar to hostnameVerifier in Java
I want to create a LDAP authentication for my OSS Nexus repository.
I use below info
Protocol : ldap
Authentication method : DIGEST-MD5
But When I create a LDAP connection in Nexus OSS it getting below error
Failed to connect to LDAP Server: a.b.c.d:636; socket closed
connectivity from My repository to LDAP server is OK.
What is the issue.
the ldap works on port 389 and it operates on 636 for ldaps. you might need to add the certificates you can do:openssl s_client -showcerts -connect server.com:369.This command will give you pem's you can copy and paste it through ui to ssl certificates.
I enabled TLS in NiFi by running the below command,
nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/bin/tls-toolkit.sh standalone -n "{my-ip},localhost" -C 'CN={my-ip}' -C 'CN=localhost' -o ./certs
This created the files required for TLS under the directory certs.
I moved the files under the directory certs into the conf folder of the deployment in my machine.
Installed the certificate to my machine's Keychain Access.
Now started the server using bin/nifi.sh start. My server starts, I am able to hit the server, But my request is not authorized.
I am getting the below error,
Not authorized for the requested resource. Contact the system
administrator.
Once TLS is enabled in Apache NiFi, anonymous access is no longer enabled by default. You will need to authenticate as a user in order to access the UI/API. There are three authentication mechanisms available -- client certificates, LDAP, or Kerberos. Once you configure an Initial Admin Identity in $NIFI_HOME/conf/authorizers.xml (this would be the exact CN of the client certificate you issued in the TLS Toolkit command), that user can authenticate and use the user management tools in NiFi to add additional users.
You can find more information in the NiFi Admin Guide. Bryan Bende has also written a detailed walkthrough of the process.
One note about the command you posted above -- I am not sure what your desired output is, but the command is issuing a server certificate for my-ip and another for hostname, but then two client certificates with those DNs as well. In general, you want a server certificate for hostname (possibly with a SAN entry for my-ip), and a client certificate with a DN like CN=alopresto, OU=Apache NiFi.
For example:
./bin/tls-toolkit.sh standalone
-n 'nifi.nifi.apache.org'
--subjectAlternativeNames '123.234.234.123'
-C 'CN=alopresto, OU=Apache NiFi'
-P password
-S password
-B password
-f ...conf/nifi.properties
-o ...conf/
I want to use Cloudify 3.1 with my Openstack in my company.
Unfortunately, I had the prolem that the keystone authentication failed.
When I see the log,it says,"SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"
I think it is HTTPS that make it failed. I see the curl below.
curl -i 'https://identity.example.com/v2.0/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "xxxx", "passwordCredentials": {"username": "xxxx", "password": "xxxxx"}}}'
HTTP/1.0 200 Connection Established
Proxy-agent: Apache
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
How can I make the curl succeed without using -k or --insecure?
OR IF ANYONE HAS THE EXPERIENCE TO DO WITH openstack THAT KEYSTONE IS USING HTTPS WHEN INSTALLING Cloudify?
Using Openstack services with insecure SSL certificates is not possible in Cloudify 3.1. However, in Cloudify 3.2 it's possible to pass the --insecure (or ca_cert) flags directly to be used by the Openstack clients.
You can read the documentation for this feature here:
http://getcloudify.org/guide/3.2/plugin-openstack.html#openstack-configuration
So, for example, to use Nova service with insecure certificate, your Openstack configuration could look something like this:
openstack_config:
...
custom_configuration:
nova_client:
insecure: true
Hope this helps.
The SSL certificate could be invalid for a number of reasons. I've even seen where people forgot to reload the web server after updating the certificate. But, it is telling you what the overall problem is - you need a valid SSL certificate that is installed correctly.
Using curl -k or curl --insecure is perfectly fine in a development environment. For production, you can use an SSL Checker to test the SSL certificate and find out why it is being reported as invalid.
Recently,I look the github of cloudify.
They are resolving my problem,the problem linkenter link description here
the work is on progressing.