If i connect to a remote server that uses SSL my browser would request its digital certificate from the server and the server would get it from its key-store am i correct ?
Is java key-store tool being used to perform the same action ?
The Java keytool.exe utility is used to maintain digital certificates and their associated keys in a key-store file. It can also be used to generate key-pairs, signing requests and for other security-data oriented functions.
Related
I want to transfer a few files weekly from mainframe to a Linux server running RedHat using a batch (JCL) job using FTPS.
Linux server is configured with vsftpd. Is it possible to send file from mainframe to linux using FTPS?
Getting this error while transferring the file from mainframe to Linux.
EZA1736I FTP
EZY2640I Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration parameters.
EZA1450I xxx FTP CS xxx
EZA1456I Connect to ?
EZA1736I host_name
EZA1554I Connecting to: host_name xxx.xxx.xxx.xxx port: 21.
220 (vsFTPd 2.0.5)
EZA1701I >>> AUTH TLS
234 Proceed with negotiation.
EZA2897I Authentication negotiation failed
EZA1534I *** Control connection with host_name dies.
EZA1457I You must first issue the 'OPEN' command
EZA1460I Command:
EZA1618I Unknown command: 'Atul'
EZA1619I For a list of the available commands, say HELP
EZA1460I Command:
EZA1736I Summer#123
EZA1618I Unknown command: 'Monsoon#123'
EZA1460I Command:
EZA1736I cd /home/Atul/
EZA1457I You must first issue the 'OPEN' command
From your log you seem to be able to set up an unsecured connection to the FTP server. That's good.
EZA2897I Authentication negotiation failed indicates that the TLS-handshake did not complete successfully. Either the partners could not find a common TLS-version and/or ciphersuite or (that's the point I'd examine first) the certificate provided by the FTPs-server isn't trusted by the client user. To be sure you would have to capture and examine a TCP- or TLS-trace.
In a first step I would check the certificate provided by the FTP server and compare it to the trusted certificates in your security manager. In the case of RACF you would have to examine SITE-certificates and/or certificates in the user's keyring.
Yes, sending from the mainframe using FTPS to VSFTP is certainly possible. Both the client (z/OS in this case) and server (Linux in this case) need to agree on the encryption method to be used and I believe by default, z/OS has to trust the certificate for the server, which may involve importing the certificate bundle to a key ring that the batch job has access to. The job not having access to a keyring that trusts the chain for the server certificate would be my first guess.
I don't have experience with setting up the RACF keyring things, but I can say that people do successfully send us data every day from z/OS to our Linux server via FTPS.
I'm trying to establish 2 way SSL MQ connection from node js application via 'ibmmq' node module. Is it possible to configure truststore and keystore (SSL configs) with ibmmq? If so, how should it be configured?
See comments in the amqsconntls.js sample.
As it's built on the C client, the Node.js layer requires a kdb-format store which combines the role of keystore and truststore. Use of that store from client programs is described in the MQ knowledgecenter - various mechanisms including program-specified, ini file and environment variables can be used to access it depending on your requirements.
I work on a software application that uses gRPC to establish a bi-directional stream between client and a server.
I'm looking for something similar to this ticket's answer only in java: How to enable server side SSL for gRPC?
I would like to configure my application so that they can choose what TLS scenario they want to use:
Scenario 1: plaintext (no encryption)
Scenario 2: Server-side TLS
Scenario 3: Mutual TLS
For TLS setups, I am using Java on non-Android environments, so I will only be considering the OpenSSL installed scenario using https://github.com/grpc/grpc-java/blob/master/SECURITY.md#openssl-statically-linked-netty-tcnative-boringssl-static
Configuring the server side seems pretty straight forward because it is documented quite well: https://github.com/grpc/grpc-java/blob/master/SECURITY.md#mutual-tls
Here would be the steps for the corresponding TLS options:
Sever-side configuration for Scenario 1: Use builder.usePlaintext
Sever-side configuration for Scenario 2: Add a NettyServerBuilder.sslContext built by SSL Context Builder with GrpcSslContexts.forServer and set the cert chain and cert key (and password if needed)
Sever-side configuration for Scenario 3: Add a NettyServerBuilder.sslContext built by SSL Context Builder with GrpcSslContexts.forServer and set the cert chain and cert key (and password if needed), and also set a trustManager on the sslContextBuidler set to the trust cert file.
The server-side part is well documented which is excellent.
Now I want to configure a NettyChannelBuilder on the client side. The only thing I can find information on this is in this unit test: https://github.com/grpc/grpc-java/blob/master/interop-testing/src/test/java/io/grpc/testing/integration/TlsTest.java
Here are the configurations I think are needed, but need to get confirmation on.
Client-side configuration for Scenario 1: Use nettyChannelBuilder.usePlaintext(true). This will disable TLS on the netty channel to grpc.
Client-side configuration for Scenario 2: Set the sslContext using nettyChannelBuilder.negotiationType(NegotiationType.TLS).sslContext(GrpcSslContexts.configure(SslContextBuilder.forClient(), SslProvider.OPENSSL).build()). This will configure the channel to communicate through TLS to grpc server using the default ciphers and application protocol configs.
Client-side configuration for Scenario 3: Set up TLS for the netty channel using nettyChannelBuilder.negotiationType(NegotiationType.TLS).sslContext(GrpcSslContexts.configure(SslContextBuilder.forClient(), SslProvider.OPENSSL).sslContextBuilder.trustManager(clientAuthCertFile)
.clientAuth(ClientAuth.OPTIONAL).build()) where clientAuthCertFile is the trust cert file and ClientAuth.OPTIONAL can also be ClientAuth.REQUIRED if you require mutual TLS.
Is there anything incorrect with my client-side configurations? Do I need any tweaks? I will add this as a PR to the security.md file after getting some blessing from the community on this post.
I added a hello world TLS PR to the grpc-java project here https://github.com/grpc/grpc-java/pull/3992
the latest version of grpc-java as soon as this pr is merged will have a really nice working hello-world example. So all you have to do is git clone that project from master, and look at the example/README.md.
Does Node.js support certificate pinning? More specifically, if a server passes a HPKP header on the first connection, will Node.js honor that setting?
Note that this is for library in which a client connects to my server. I don't care if the HTTPS server in Node supports certificate pinning.
I also understand that I can inspect the certificate manually and there are a few third party libraries which will check on every connection or monkey patch the request library. I'm not asking about that functionality, either.
My plan is to check the certificate the first time and reject if it doesn't match. However, that doesn't do me any good if the TLS cert is changed after that first call.
Use res.socket.getPeerCertificate().fingerprint property of HTTPS response, compare it with your preshared value.
I need to secure my .NET Remoting by SSL.
I'm using TCPChannel and I can't switch to HTTPChannel and use IIS to add the SSL.
Thus, what I figured out, I need to create my own Sink that will encrypt the streams going to/from Client/Server. For that, I found good article at MSDN: http://msdn.microsoft.com/en-us/magazine/cc300447.aspx. However, that article is developing the crypt, handshake, etc.
I do not want to "reinvent the wheel". I'm afraid of making mistakes when developing this logic on my own. I would rather like to use some SSL implementation (e.g. SslStream or OpenSSL) that will do that stuff for me.
Can I use SslStream or OpenSSL in .NET Remoting with the TCPChannel?
Would you suggest a simple usage?
Thank you for your help.
Consider switching over to WCF.
Alternatively, Remoting should be able to do the equivalent of using WCF with ClientCredentialType set to Windows, if you specify secure='true' in your remoting configuration on both client and server side. TcpChannel will start using SSL under the hood to encrypt the communication, using user credentials for key material. On client side, this also has the implied effect of setting tokenImpersonationLevel='identify' which means that the server will not impersonate the user account under which the client is executing, but it will know who connected to it (assuming the client and the server run in the same AD domain). For performance reasons, set useAuthenticatedConnectionSharing to true on the client side.