I am facing invalid certificate errors on attempt to authenticate to open ldap server over ldaps. I know my ldap bind settings are valid as I can connect over ldap on port 389. but when i change my connection to ldaps, I am getting certificate errors, I am using self signed certificate on my open ldap server (full fqdn of ldap server is in the certificate CN). I have verified this certificate is valid on other client systems connection over ldaps to this server.
My question is - could the problem be with the ldap client and the certificate it is presenting on the ldap connection attempt? Does my ldap server need to trust the clients certificate? I understood it was not necessary but might be wrong?
here is the error on ldap client side:
ldap_initialize( ldaps://<my_ldap_server_fqdn>:636/??base )
Enter LDAP Password: TLS certificate verification: Error, certificate is not yet valid
TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (certificate is not yet valid).
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
No match found.
Related
In our platform, the client will generate their own self-signed certificate. We will then validate the certificate external from the nginx. I use optional_no_ca and not verify the client with a trusted CA. I perform verification on the server side after nginx
I am now building the production environment with API Gateway and ALB. However, I do not know the equivalent of optional_no_ca. I want the client to verify the server cert but the client certificate should pass through to the server for some application checks.
In the TLS handshake process, the Certificate Verify message will follow the Client Key Exchange message after the server requested a client certificate. The Certificate Verify contains a digital signature computed over all previous handshake messages including the type and length fields of the handshake messages. This process allows the client to prove that it owns the private key of the client certificate it sends to the server.
The idea came from a practical problem. There is an mTLS enabled server that conducts different action policies based on the client certificate received, for example, different welcome pages for different client certificates. If a layer-7 reverse proxy service like the load balancer is placed in front of the proxied server which also requires decrypting the TLS traffic. The proxied server can only get the client certificate information from the HTTP header (for example, set proxy_set_header with $ssl_client_cert variable in NGINX) which requires modifying the logic of the server.
A simple but very troublesome solution is the reverse proxy service stores all the client certificates and their private keys. The reverse proxy service will use the same client certificate it received during the mTLS handshake process to establish the mTLS connection with the proxied server.
Since the reverse proxy service can choose whether to trust the client or not with its own implementation, it is possible to forge the Certificate Verify message by asking the client to send a second Certificate Verify signature when the proxied server needs the reverse proxy service to do so (I know it's like a man-in-the-middle attack)?
I have applied a free certificate for my website and successfully installed the certificate in the certificate store. And the CN is the same as my domain(issued to mydomain).
I also set up the site bindings and added an https binding using the free certificate.
The port 443 is opened for both inbound and outbound.
Windows Network Troubleshooting detected the resource(my domain) is online but isn't responding to connection attempt.
But I still get ERR_CONNECTION_TIMED_OUT error from the browser.
Did I miss any steps? How could I enable the https in IIS?
UPDATE 11/14/2018
I have run bindings diagnostics and SSL diagnostics using JexusManager suggested by #Lex Li, and got more information as below:
Binding Diagnostics:
BINDING: https *:443:whatever.com
This site can take external traffic if,
TCP port 443 must be opened on Windows Firewall (or any other equivalent products).
Requests from web browsers must be routed to following end points on this machine,
[::1]:443.
My.private.IP.address:443.
This site can take local traffic at 127.0.0.1:443.
This site can take local traffic at [::1]:443.
Web browsers should use URL https://whatever.com:443. Requests must have Host header of "whatever.com".
Start DNS query for whatever.com.
DNS Query returns 1 result(s).
127.0.0.1
Binding Diagnostics does not verify certificates and other SSL/TLS related settings.
Please run SSL Diagnostics at server level to analyze SSL/TLS configuration.
And then I ran SSL diagnostics as below:
BINDING: https *:443:whatever.com
SSLCertHash: 2962cd5b2b450403bce520169c268de1f17a6216
SSL Flags: None
Testing EndPoint: 127.0.0.1
CertName: whatever.com
Version: 3
You have a private key that corresponds to this certificate.
Signature Algorithm: sha256RSA
Key Exchange Algorithm: RSA-PKCS1-KeyEx Key Size: 2048
Subject: CN=whatever.com
Issuer: CN=TrustAsia TLS RSA CA, OU=Domain Validated SSL, O="TrustAsia
Technologies, Inc.", C=CN
Validity: From 11/11/2018 4:00:00 PM To 11/12/2019 4:00:00 AM
Serial Number: 0B365B8ABC8118CD7F818FD5B7BB485C
DS Mapper Usage: Disabled
Archived: False
Subject Alternative Name: DNS Name=whatever.com DNS Name=www.whatever.com
Key Usage: KeyEncipherment, DigitalSignature
Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1),Client
Authentication (1.3.6.1.5.5.7.3.2)
Basic Constraints: Subject Type=End Entity, Path Length Constraint=None
Certificate verified.
And, I also have run an SLL Checker and it returns:
whatever.com resolves to My.Public.IP.Address
Server Type: Microsoft-IIS/8.5
No SSL certificates were found on whatever.com. Make sure that the name resolves to the correct server and that the SSL port (default is 443) is open on your server's firewall.
The certificate passed the SSL Diagnostics but it has some problem. I didn't get it. How could I enable https protocol for my site? Many thanks!
Problem solved.
As #John Wu said, this is not a programming problem but a network gateway problem.
First, the certificate has no problem and so does the server/firewall setting.
The problem occurred in the network gateway of the cloud service provider that blocked the 443 port inbound and outbound. In my case, I am using AliCloud server and it blocked every request which went through 443 port from the public network. And this is why I could only get access to the SSL website through the browser on the server.
The solution is very simple. The only thing needs to do is to inform the cloud service provider to open the 443 port. In my case, I just added the 443/443 port authorization in the control panel of the cloud servers and then everything fixed.
Is it possible, in general, for a server to require both client certificate authentication and BASIC authentication?
For example, an intranet site of some sort, which requires :
The machine to have a specific certificate installed (client cert authentication), AND
A valid user to log in (basic authentication)
NOTE: this question isn't about a server supporting one or the other, but both together (as in the requester must authenticate both ways)
Yes, it is possible to have both. The client certificate will be verified during the TLS handshake while basic authentication will be done at the HTTP level, i.e. inside the TLS connection after the TLS handshake is done and the client certificate checked.
I use the same certificate both for client and service authentication on Wcf with message security. Does it cause any serious vulnerability?
You don't want to have the full certification on both the server and client for security reasons. Have a look at this Server / Client Certs