Trying to use ruby GRPC client to connect to a go GRPC server. The server uses TLS credentials with self signed certificates. I have trusted the certificate on my system (ubuntu 20.04) but still getting Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
Only way this is working is by manually setting GRPC::Core::ChannelCredentials.new(File.read(cert_path)) when initializing the client. Another workaround is setting :this_channel_is_insecure, but this only works if I remove TLS credentials in the server altogether (which I do not want).
Is there any way to get the GRPC client to work with the system certs?
I assume the gem is using roots.pem and trying to override that using GRPC::Core::ChannelCredentials.set_default_roots_pem results in Could not load any root certificate.
Also, I have not found any parameter that would let me skip certificate verification.
The default root location can be overridden using the GRPC_DEFAULT_SSL_ROOTS_FILE_PATH environment variable pointing to a file on the file system containing the roots. Setting GRPC::Core::ChannelCredentials.new(File.read(cert_path)) also seems fine to me.
In Ruby, most likely the feature to skip cert verification in TLS is not supported. We have the corresponding feature supported in underlying core, but it might not be plumbed to Ruby yet(at least not that I am aware of). If you need that, feel free to open a feature request to in gRPC Github page.
Thank you!
Related
For the past few days, i've been trying to configure freeradius to authenticate wifi clients in OpenLDAP (without TLS - 389 bind).
I tried several guides and did not get the result i was looking for.
At localhost, RADTEST works and i receive an Accept-Accpet.
User is found within LDAP and accepts authentication.
When i try to authenticate via wifi (Windows 10), i can't connect.
The configuration i am currently using is this:
https://gitlab.com/ae-dir/client-examples/-/blob/master/freeradius/radiusd.conf
Someone with experience integrating freeradius with openldap?
I need wifi clients to connect with their ldap credentials.
You have not explained more details about the authentication method you are trying to use. This is important. However, a simple recipe for making freeradius+ldap authentication work with Windows10, Ubuntu and Android in EAP/TTLS mode is as follows:
Make sure the radius server has access to the LDAP server. Also make sure that the clients (access points) have access to the radius server. Check firewall issues and freeradius configuration (for Debian10 the file is /etc/freeradius/3.0/clients.conf)
For the authentication test (taking into account that the previous step has already been certified by you), there are two interesting tools: radtest (part of the freeradius-utils package) which does not support EAP/TTLS authentication, and a tool called eapol_test, which is part of the wpa_supplicant package and supports EAP-TTLS.
Follow the EAP/TTLS configuration steps and how to use the eapol_test tool on this link.
Make sure you generate the new certificates (don't use snakeoil certificates at all) and don't forget to change the certificate settings in /etc/freeradius/3.0/mods-enabled/eap). The link from the previous step does not talk about this step.
Run freeradius in full debug mode to find any errors (ie freeradius -X).
Don't forget to check the password and protocol compatibility list.
I received the following question. Any help would be greatly appreciated!
What I need to be able to do is configure SSL to validate the target endpoint’s SSL certificate against the base trusted roots (typically provided by the OS and/or Java). There is no documentation that tells me how to turn on SSL certificate validation or if I add a TrustStore if it will guarantee that the SSL cert is validated against that. The only tutorial I see that is related is for SSL Client Auth, which we are not using.
Validation of backend SSL server certificates is explained on this page. Note that the page documents how to achieve mutual authentication, where the gateway would both validate the target server's SSL certificate (which you want), and send a certificate to the target as identification (which you do not want).
To validate the target's certificate, you create a truststore and upload all certificates in the trust chain for your target server. The documentation mentions only uploading the target server's certificate (which works if your target server is using a self-signed cert), but you'll want to upload the entire trust chain of certificates if you are using a non-self-signed cert. Creating and uploading to the truststore is shown in step 6 on the page above.
Then, you'll want the target endpoint configuration to look like this:
<TargetEndpoint name="default>
<HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>false</ClientAuthEnabled>
<TrustStore>myTruststore</TrustStore>
<IgnoreValidationErrors>false</IgnoreValidationErrors>
</SSLInfo>
<URL>https://myservice.com</URL>
</HTTPTargetConnection>
</TargetEndpoint>
ClientAuthEnabled=false indicates that the gateway will not send a certificate to the target.
IgnoreValidationErrors=false will cause the connection to abort if the certificate returned by the target cannot be validated using the certificates in the truststore. IgnoreValidationErrors=false is the default, so you could leave it out and it would work as desired. However, if you are having problems communicating with your target server, it may be useful during testing to set the ignore flag to true to allow communication even if the certificate fails verification (just to isolate your problem). Just be sure to set it to false in production.
The xsd schema for the SSLInfo element can be found here.
My question is so far, a purely theoretical one.
I want to make a CMS that supports multiple sites.
The question I haven't been able to figure out so far is this one:
How do I attach the ssl certificate for https protocol from the code-behind, instead of attaching it through the hosting interface or on the iis itself (the main problem is that i want a different ssl certificate for every site, instead grouping them on one certificate, which allows maximum of 5 domains, and will still say they are the same entity)
This is not solvable on ASP.NET level.
The reason is that with HTTPS requests the SSL handshake (where certificates are presented) is performed before the client sends HTTP request, from which you can learn the domain.
The only exception is server-name-indication extension in TLS, which lets the client specify the desired domain in SSL request. But this extension is not supported by many clients and it's not present in still used SSL3 protocol version. And even with this extension it's the SSL server that decides which certificate to present.
As mentioned by Eugene, administering the SSL cert is beyond the level of ASP.Net; however, you may create some form of administration routine to execute the command-line tool for IIS7 (and up) AppCmd.exe to manage the certs:
ie (shell command --security rights is important):
appcmd.exe set config -section:system.applicationHost/sites /+"[name='Default Web Site'].bindings.[protocol='https',bindingInformation='*:443:']" /commit:apphost
The System.Security.Cryptography.X509Certificates.X509Certificate namespace might also come in handy.
I've a quick question:
I have 2 websites, 1 has some links to file downloads. Those files are hosted on another server.
I need to encrypt the request data between the 2 servers..can I do it just using a SSL certificate?
Any other/better idea?
Those files are private docs, so I don't want the server 2 or any other people being able to track the file requests between the servers.
Thanks
Yes, use SSL (or actually TLS) if you want to achieve transport level security. If these are two servers that you control you can configure your own self signed certificates. If you want to make sure that only the two servers can communicate with each other, then require client-authentication, where both the server and client use a certificate/private key pair.
Most of the time the trick is to implement a sensible key management procedure. Setting up a web server to handle TLS using certificates should not be too hard.
SSL certificate will work fine for ensuring the transfer is encrypted. Even just a self signed certificate will be fine for this purpose (provided you can tell the client you're going to use to accept the self signed cert)
Alternatively if it's two linux machines then scp (secure copy) is a great tool where it'll connect via ssh and grab the files. (There probably is a windows scp tool but I don't know it)
Rsync also supports going via ssh
As for tracking the request... there's nothing you can do to prevent any device between your computer and the destination computer logging the fact a connection was made but the encryption should prevent anyone from getting to the actual data you're sending.
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.