I am using LDAPS authentication with Open source CMS ez publish. I have made all the configuration settings that I am suppoed to make. But, I still cannot get LDAPS authentication to work!
on debugging, I found that ldap_connect fails and it returns resourse id #80 or resource id #75 sometimes. Is there any documentation that describes what these resource ids mean? Even the php documentation of ldap_connect doesn't have any information on these resource ids. Or is there some thing else that I could have done wrong?
The PHP manual on resources. Seems like ldap_connect() is successful. If it fails, it returns FALSE.
The most common SSL related issue is trusting the certificate used in the connection.
If your LDAP servers SSL cert is not signed by a well known CA, or more correctly, by a CA known to your SSL library then it usually will fail. To resolve this you have to make your SSL library trust the CA.
Windows (IE), Firefox, Safari, etc all have their own keystore mechanisms and you can import certificates of the CA's Trusted Root into them. Then all certificates signed by that CA are now trustworthy.
Java uses JKS keystore files, old Netscape uses cert.db7 or cert.db8 files. No clue what PHP uses, however you ought to figure that aspect out.
Related
I am working on some 3rd party integration project.
Created RootCA and SubCA from their official documentation website and after importing in windows server, we created key using openssl and got signed certificate from 3rd party integration Support team
We have configured in ldp.exe client and it got connected and fetched the dataset.
Now we are implementing in PHP code level.
We have:
IIS server 10
PHP 7.2
PHP Code is working in IIS
Added ldap.conf file created c:/openldap/sysconf/ldap.conf
TLS_REQCERT allow
#TLS_CACERT c:\openldap\sysconf\RootCaSha1.der
TLS_CACERT c:\openldap\sysconf\SubCaSha1.der
#TLS_CACERTDIR c:\openldap\sysconf
We have tried various paths and noted all evidence via wireshark tool
It says TLSv1.2 Alert (Level: Fatal, Description: Handshake Failure) so it means some certificate in ldap.conf are not as per requirement.
Looking forward to help in this regard so we can get connect.
Thanks in advance
As far as I know, the TLS handshake failure error commonly occurred when the server’s certificate is configured improperly. this should be configured on the IIS server-side. Please check the below items.
The account running the website is supposed to own the right of accessing the private key of the certificate. Firstly import the certificate to the Local machine Certification Store, under the property page of the certificate, grant the account access to the private key of the certificate.
Subsequently, we specify the certificate in the IIS site binding module.
Besides, Please note that the communication between the client-side and the server-side is established based on the fact that the client trusts the server certificate. this means that when we visit the website, the browser address bar has the sign of security lock. In this way, the public key of the certificate can be exchanged. The specific operation is to add the server root certificate to the Trusted Root Certificate Authority certification store of the client-side.
I'm using the PHP userland library, found here: https://github.com/mongodb/mongo-php-library
, with documentation at: http://mongodb.github.io/mongo-php-library/classes/client/
How do I supply SSL options and which constructor to use? I'm assuming MongoDB/Client but documentation is sparse.
I have the usual on the server; CA file, server certificate and private key file with net.ssl being set to requireSSL.
So if anyone has tried anything, it'd be great if you can list what worked.
Update
A lot of googling took me to this page. and I could only get the mongo shell connected successfully, but definitely not through the php library. I am using MongoDB 3.2.1 on Centos7.
Additionally I see that client certificates need two additional fields in the x509 certificates[keyUsage = digitalSignature, extendedKeyUsage = clientAuth], as narrated here. Now although that isn't impossible, but isn't a very manageable or scalable way for my implementation in my opinion.
Also a strange thing I discovered is that the CN in the final client certificate needs to be "localhost.". You cannot omit the last period. And the --host argument accordingly has to be "localhost." (not just localhost) or else the validation fails. But if you try to create a certificate with the CN as just localhost, you will never be able to connect to the server and the validation would fail everytime.
I have a SSL enabled eCommerce website which uses cURL for payment processing. Everything is running well but recently I learned about "CA Public Certification Bundle for cUrl" that its a good idea to use it for cURL connections.
If this is true than can someone tell me how or how is it better/different than using the standard SSL?
Doesn't the SSL already provide some kind of certification for all connections?
Any HTTPS client connected to an HTTPS server will get its certificate (in fact, it can be a certificate chain). This server certificate must then verified by the client to authenticate the server.
This is normally done by using a number of CA certificates that are configured on the client as trust anchors (i.e. this is what you trust in advance, before encountering the server certificate). The client tries build a chain between the last element of the server chain and one of the CA certificates in its trust anchors. If there is such a valid chain the server certificate is trusted.
A "CA certificate bundle" would be a set of trust anchors. You can build your own by looking for CAs you're willing to trust, or you can use an existing bundle. Most OSes or browser come with an existing bundle. cURL in itself doesn't but it can rely on a pre-defined location (set at compile time) or it also suggests to use the Firefox bundle (via a conversion mechanism). (You can override default setting via extra options, on the command line or via the API.)
Certificate Pinning (which you also mention) has nothing to do with a CA cert bundle. In fact, it's almost the opposite. Instead of relying on 3rd party trust anchors (the certification authorities), you explicitly "pin" a set of server certificates you know as directly trusted. They're not used to verify other certificates, instead, you compare the certificate you get with the exact certificate you're expecting for that host (or at least you compare public keys). This is more like having a reference mapping from server name to certificate (or to public key) and comparing what you get from that host with the reference you have. Of course, this can only work for a reasonably small set of certificates in practice, unlike the CA (PKI) approach which is designed to let you authenticate parties you have never encountered before (via a 3rd party: the CA).
How is it better/different than using the standard SSL?
Doesn't the SSL already provide some kind of certification for all connections?
Using a CA certificate bundle isn't different than using "standard SSL", it is what's commonly used for SSL/TLS connections. You often don't see it because that CA bundle is often supplied with your client (or with the OS).
Note that strictly speaking, this is orthogonal to SSL/TLS itself, which mainly just says you should authenticate the server. Certificate verification (the PKI way, via CA certificates) is defined in a different specification, also complemented by a specification on how to verify the name in the certificate (and the HTTPS specification of course).
Found a great answer here. The comment above really helped. The exact keyword I was looking for was "Certificate Pinning".
I'm familiar with the public/private key negotiation implemented in HTTPS, which is why I am confused by the following driver options that are apparently available (though not officially documented) for PDO's MySQL driver:
PDO::MYSQL_ATTR_SSL_KEY
PDO::MYSQL_ATTR_SSL_CERT
PDO::MYSQL_ATTR_SSL_CA
The link suggests they point to files stored locally - yet why would a copy of anything besides the CA certificate be stored on the client? Has anyone successfully made an encrypted connection using this method?
This pertains to client certificates that the client must have in order to be able to connect to the server, i.e. that the client must verify its identity (yes, SSL can work the other way around as well). Start by reading the general section Using SSL for Secure Connections, then see the REQUIRE clauses in the GRANT syntax:
REQUIRE X509 means that the client must have a valid certificate but that the exact certificate, issuer, and subject do not matter. The only requirement is that it should be possible to verify its signature with one of the CA certificates.
REQUIRE ISSUER 'issuer' places the restriction on connection attempts that the client must present a valid X509 certificate issued by CA 'issuer'. If the client presents a certificate that is valid but has a different issuer, the server rejects the connection. Use of X509 certificates always implies encryption, so the SSL option is unnecessary in this case.
...
Currently setting up a backup solution that sends a database dump and some other files from a Wordpress network to a NAS on my LAN, via WebDAV. I have installed PHP WebDAV on my web server and the basic code to get that that to work is:
webdav_connect('http://webdav.example.com/dav', 'davuser', 'davpassword');
webdav_put('/your/nice/thing.txt', $data);
webdav_close();
The issue is, my NAS requires this connection to be done via HTTPS, so in a web browser you'd see a warning which you can ignore, but PHP gives the following warning and the code fails:
Warning: webdav_put() [function.webdav-put]: Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted in /var/www/vhosts/blah/blah/blah.php on line 5
Is there a way in which I can ask PHP to ignore this, or will I need to obtain an SSL certificate? The domain name used for accessing the WebDAV service on my NAS is one provided by Dynamic DNS if that makes a difference.
Is there a way in which I can ask PHP to ignore this, or will I need to obtain an SSL certificate?
I don't know which HTTP Layer PHP WebDAV uses (which extension are you using?), but often it's possible to configure the underlying layer to ignore certificate errors.
If you need certificate verification for security reasons, you should obtain a valid certificate.
Just for completeness as I don't like leaving things un-answered. I've decided to access my WebDAV service via SMEStorage. They provide an API which developers can use for this sort of thing:
http://smestorage.com/?p=static&page=for_developers