I have been trying to configure SNMP over TLS. I need to send INFORM messages.
I referred to
How do you use asymmetric keys or certificate authentication in SNMP4J?
It provides nice explanation but I have some more questions such as following,
What should keystore contain, agent (snmpd) or manager certificate? I believe keystore should exist on the system from where the connection is being made through SNMP4j library.
What should trust store contain? Where should it reside, agent or manager?
Do we need to store private keys in keystore and trust store?
What should be passed to CertifiedTarget constructor, agent certificate alias or manager certificate alias?
E.g. CertifiedTarget ct = new CertifiedTarget(new OctetString("alias"));
I have the same question for certificate alias passed to DefaultTlsTmSecurityCallback.addLocalCertMapping().
E.g. securityCallback.addLocalCertMapping(ct.getAddress(), "snmpagentalias");
If I run the code provided in How do you use asymmetric keys or certificate authentication in SNMP4J?, it always returns null response PDU.
Any help would be appreciated. Thank you.
Related
Currently I want to expose a gRPC Method as Public API and protected by Auth0 (JWT Token), with Istio(Envoy Proxy) will help validating the token on server side. Since the JWT Token is not encrypted by the standard (it is only used to end-user authentication and authorization layer), I want to encrypt the communication using TLS. Also, my public server already have valid certificate.
The problem is on the gRPC Client side. Every example I look, the gRPC Client have to initialize the TLS Connection with server cert pem file. Is it really necessary? Because it adds operational burden and complexity, where we have to distribute our server pem file everytime we renew the certificate AND/OR the client side has to restart the application.
Thanks,
Agung
If you are using a self signed certificate, then yes you must explicitly trust it in your client. If you use a publicly signed certificate on your Server, gRPC will use the Operating System's certificate authorities to verify the cert. (In the case of Java, it uses the JVMs cert authorities.)
If you are using a self-signed certificate you need to specify the server's root certificates in the pem_root_certs member of the SslCredentialsOptions struct passed in when creating a channel, as Carl says.
However if you are using a CA issued certificate, leaving the pem_root_certs member empty will cause gRPC to default to its own master list (reviewable online), not any OS-specific list.
Based on this answer: https://stackoverflow.com/a/3107645/1559672 it's possible to set up ssl connection without user verification.
I think the answer to my question would be yes but can't find anything to confirm/reject it.
The idea is that the server has a certificate that the client can verify via a CA. Then client generates some secret and encrypts with server's public key. Based on this shared secret they generate 'key material' for encryption/decryption. After they have the secured connection, client can verify itself with username/password.
Is it possible like this? if yes, please show me some example or proof.
If not, why not?
The reason of confusion was because of RabbitMQ doc: rabbitmq.com/ssl.html "Connecting without validating certificates" 's example code doesnt define what server certificates or RootCAs are accepted. (RabbitMQ cert is self signed) So I don't get how TLS is set up without that?
Encryption does not depend on certificates. And a self-signed certificate is still a valid certificate.
The purpose of certificates is to prove the identity of the remote peer. Can you really be sure you're talking to the server you think you're talking to and that your connection isn't currently being hijacked? This is ensured by the server presenting a certificate only it could have (public/private key crypto validates this, only the server should have the private key for the certificate; trust/security here depends on the server keeping its private key to itself).
How do you trust the certificate? Well, you may have a copy of it in your trusted certificate store. You'd do this with a self-signed certificate: just put it in your trusted store; since you (presumably) know where it came from, it's trustworthy.
Since this is unrealistic for every public site on the web, a public key infrastructure exists which allows you to trust a limited known number of certificate authorities which can sign certificates of arbitrary unknown parties, and you can indirectly trust those heretofore unknown certificates.
Having said all this, encryption is a separate component and an encrypted, secured connection can be set up with or without the identity verification that certificates provide.
I'm reading about certificate-based authentication in SSL, and got a question about this process. (picture is taken from above link)
Question is: why server.cer and client.cer are not secrets. In this diagram, it seems that communication hasn't been encrypted when certs got exchanged, does this mean both certificates are exposed in plaintext? If so, why it's secure? Because in this way an adversary can easily obtain server's public key as well as its certificate, and impersonate the server. I think I misunderstood something. Please correct me.
Because in this way an adversary can easily obtain server's public key as well as its certificate
Correct.
and impersonate the server.
Incorrect. You need the private key as well as the certificate to impersonate the server.
The diagram you quoted isn't correct. Both sides will have not only a keystore but a truststore. The incoming certificates are checked against the local truststore; the outgoing certificate comes from the keystore.
given that the certificate is used to verify the public key belongs to the server
No. The certificate plus its digital signature is used to verify that the certificate belongs to the server. The digital signature is created with the private key. See the article you quoted.
However it isn't entirely correct. In the diagram, incoming certificates are checked against a local truststore, which is separate from the keystore. The session key is never exchanged (2.1 step 5).
I am tring to figure out how a secure connection between client and server is established. I tried the SSL example provided by boost::asio library. My question is about the certifacte used by client and server. To be specific, I generated a private key(mykey.pem). Then I used this private key to generate a self-signed certificate(mycert.pem) and I used these files as follow:
Server side:
1)context_.use_certificate_chain_file("mycert.pem", error);
context_.use_private_key_file("mykey.pem", boost::asio::ssl::context::pem, error);
context_.use_tmp_dh_file("dHParam.pem",error);
Client side:
2)ctx.load_verify_file("mycert.pem",error);
With this code the handshake is done perfectly. My question is that how come both the server and client use the same certificate ("mycert.pem") in commands 1 and 2? With this approach a client can pretend to be a server easily.right? Do you think that I missed something here?
The certificate is public information.
It's the private key that allows the entity to prove its identity. The client is guaranteed by the SSL/TLS handshake that only the party with the private key matching the public key in the server certificate can be at the other end with the suitable master secret, so as to be able to decipher the communication. The problem it addresses is whether or not the remote party is indeed the one to which the certificate was issued. (This is similar to checking that the picture on the photo ID matches the person in front of you.)
Configuration of the certificate (and not the private key) on the client side is there to tell it which certificates you are willing to trust. The problem it addresses is whether or not to trust what the certificate say (in particular what it says about the identity of the server). This is normally done using a PKI, so as to build trust via 3rd parties (the CAs). (This is similar to checking that the photo ID itself is genuine, and that you can trust what it says.)
What you've done by trusting this specific server certificate is bypass the use of CAs to make an exception and indicate you were willing to trust this particular certificate to be genuine. (This is fine for a handful of certificates, but using a CA allows your trust structure to be more manageable and add other features, such as the ability to revoke certificates.)
Currently I am having a problem connecting to the server due to the following issue:
When I tried to connect to the server, it returned an error: MQRC_SSL_INITIALIZATION_ERROR
Upon closer analysis via WireShark, I found that the Client is attempting to connect to the server using SSL v2, while the server can only accept SSL V3, thus rejecting the connection.
I checked through the document, but am not able to find any information on
what SSL version the .Net client supports.
I would like to check whether the SSL version is controlled from the .Net MQ
client, and if so, how can we configure to make it connect via SSL v3?
Thanks.
I'm not sure I agree with your conclusion since WMQ has supported SSL V3.0 and TLS V1.0 since at least V6.0 and possibly earlier. This is more likely a mismatch of configurations between the client and server. The procedure I recommend to resolve SSL/TLS issues is as follows:
My method for debugging SSL connections on WMQ is to progress through the following sequence making sure each step works before advancing to the next:
Get the channel running without SSL. This validates that the channel names are spelled correctly, that a network route exists between the endpoints, that the QMgr's listener is running and that the client points to the right port. You'd be surprised how many times someone mis-keys a port or channel name.
Get the channel running with the SVRCONN definition set to SSLCAUTH(OPTIONAL). This performs an anonymous SSL connection similar to what your browser does. The QMgr presents a certificate to the client but the client is not obligated to send one back. This validates that the QMgr can find its certificate and that the client can find its trust store and properly validates the QMgr's cert. (Note: the QMgr will always request the client cert and the client will always send it if one is present. To perform this test, use a copy of the client's keystore that has the signer cert(s) but not the application's personal cert. Copy the keystore and delete the personal cert from the copy. Do NOT delete the original!)
Set the SVRCONN channel to SSLCAUTH(REQUIRED). This now requires the client to find its keystore (in the last step it required only its trust store) and to be able to find its certificate. It also requires the QMgr to be able to validate the client's cert.
Set up SSLPEER or CHLAUTH mapping rules to narrow the population of validated certificates that will be accepted on the channel.
The difference between steps #2 and #3 helps to isolate the problem by testing the SSL credential exchange in only one direction at a time. This allows you to identify whether the problem exists in the personal cert or the public cert and on which side of the channel. Nearly all problems are sorted out in these two steps.
UPDATE
Notes to respond to questions. There are two types of certificate used with SSL/TLS. The personal certificate contains the private key and is the one that doesn't get passed around. The public certificate is the one that contains the public key and can be given out freely. The private key is held in a keystore. The public keys (usually these are the CA's root and intermediate certs) are stored in a trust store. In some cases, these are separate files. For example, in Java and JMS the JSSE provider looks in the environment for variables that point to the keystore and to the trust store. It is possible in Java and JMS that the keystore and trust store variables point to the same file.
In the case of WebSphere MQ servers and clients other than Java, the keystore and trust store are combined into a single location. Often referred to as a kdb file, it is actually a CMS key database comprised of several files of which one is the KDB. In this case "keystore" is actually shorthand for a combined keystore and trust store. For the .Net client, set the keystore location and other SSL properties in the MQEnviornment.
In the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate. If the thing that signed the certificate is an intermediate signer cert (it has itself been signed by something) then the search continues up the signer cert chain until the root cert is reached. Assuming that the server is authenticated, the same procedure is applied in reverse by having the client present a cert and the server validating it.
When the process fails in Step #2 we can debug using knowledge of the process above. The QMgr must first find its cert in its keystore and present it to the client. If the QMgr cannot find its cert, the result is errors in the AMQERR01.LOG file stating this. Always look on the QMgr side first when things die in Step #2!
If the QMgr does find its cert then the next step is that client must be able to find its trust store and then within that trust store must find the necessary signer cert chain. If this fails, there should be errors on the client side to indicate that. For example, a common error when setting the client environment is to specify the entire file name, including the .kdb extension. When this happens the QMgr looks for [keystorename].kdb.kdb which doesn't exist. Another common error is that the personal certificate exists in the keystore but with the wrong label. Non-Java WMQ clients look for the certificate by label name constructed from the literal string ibmwebspheremq followed by the user ID in lower case. For example, if my user ID is TRob then my certificate label would be ibmwebspheremqtrob. Note that this is the certificate's label in the keystore and NOT the certificates Common Name or other field in the Distinguished Name.
Depending on the type of client in use, these may be in the Windows error log, local MQ error logs or other location. If you can't find client-side errors, WMQ tracing is also an option.