I have started working with LinkerD recently and trying to set it up on the cluster.
The issue I am facing is with the cert rotation. The LinkerD documentation does not elaborate completely on the process of how the issuer cert is used to generate the CSR for the Proxy request and also it does not mention how Cert Manager could be used to store the issuer cert.
If I am not missing something could you please point me to the documentation that completely elaborates the same?
Also, I want to clarify if we just generate the root cert and intermediate cert, later inject it using --identity-trust-anchors-file and
--identity-issuer-certificate-file will that work or we need to find specifically how to rotate the certs.
I may be posting on the wrong channel but the lack of documentation caused me to ask the above questions.
Related
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!
Why is there a SMTP/HTTP Protocol? I mean, why can't we use (or extend) the existing SSH protocol? Wouldn't using SSH also eliminate the need for a paid key?
Or, perhaps another why to frame this question is why do we need yet another encryption scheme?
There are different protocols for different purposes. What I'm hearing here really is 'why do we need to pay for an SSL certificate in HTTPS but not SSH'.
The reason for this is as follows:
When you first connect to a SSH server, you as the person logging in are asked to validate the public key. Do you read it and recognize the code before you accept it?
Imagine if this were needed the first time you connect to any HTTPS server. We can't ask users to validate every public key manually. How would they recognize what a public key is the correct one?
We solve this by relying on other authorities to validate the keys. These authorities don't just sell SSL certificate, their product really is validating that the person owning the domain is the one encrypting it.
So you can totally generate your own self-signed SSL certificates, but browsers won't recognize these by default. Browsers and operating system have a database of certificates they trust.
Anyway, these days you no longer need to pay for a certificate. LetsEncrypt gives them away for free.
I have a RESTful server in go, and it's behind nginx. everything is fine and we are happy with this setup (nginx and go) but now we have a websocket route for this application. (Its currently works ok with nginx in our staging server, not real load yet.)
The questions :
Is this good for my websocket route to be behind nginx too? is there any good reason for/against this?
Is there any way to bypass this route from nginx proxy and serve it directly with go? not in another subdomain or another binary.
Thanks!
I am no nginx expert but given that nobody else has answered I will present some of my research.
1) Yes, nginx is definitely a good choice for that. You can find some benchmarks here. Possible caveats are mentioned in this (older) post. The most important point to consider is the timeout aspect. These two answers give helpful information in that regard.
2) Not exactly sure what you want to achieve by that but you could simply use a different port, as websockets are not subject to the same origin policy, or use the tcp forwarding module that is described in one of the answers above.
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.
Basically, I'm using a remote object that access to a secure EndPoint. This
EndPoint is located into my server. It means that my channel is a
SecureAMFChannel. If I accept the certificat by going directly to this URL with
my browser, then I'm able to run my flex application and to exchange some data.
However, if I'dont go to this url to accept the server's certificat, and launch
my Flex application, the remoteObject is not able to accept the certificat. And
of course, any information can be exchanged.
My problem is, how to accept automatically a certificat in a Flex application.
Do I need to configure something to accept it? Maybe my manipulation is not
correct.
My certificat is self-signed, do you think that this problem could be solved by buying a Certificat signed by a CA?
Could you tell how to solve this?
Thank you very much,
Bat
You can't accept a self-signed certificate in Flex. The Flash Player trusts only those CAs that are trusted by the browser.
So, either add your own CA which you used to sign your certificate to the trusted CAs of your browser or buy a certificate from a well known CA. I'd strongly advise you to do the latter since using self-signed certificates is more or less as insecure as using no SSL/TLS at all.