I am facing a issue in jmeter. While replaying the script i am able to get http is not a trusted server in response with 403 forbidden error as a status code. The request is failing at login.
Most probably you need to supply a client certificate along with the request
In JMeter it can be done in 2 ways:
GUI mode: via SSL Manager
Non-GUI mode: via system properties
javax.net.ssl.keyStore=/path/to/file/with/certificate(s).p12
javax.net.ssl.keyStore=password for the keyStore file
The certificate can be converted/imported into the keystore using keytool or openssl or application like Keystore Explorer
More information: How to Set Your JMeter Load Test to Use Client Side Certificates
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 am using CometD library for nodejs on server side using the https://www.npmjs.com/package/cometd-nodejs-client. The server (Genesys) that I am trying to connect uses SSL, due to SSL cert I am getting SSL error when connecting to the server using CometD. My question is that is there a way to pass the ca cert to CometD library (https://www.npmjs.com/package/cometd)?
The XMLHttpRequest provided by the CometD library exposes a _config() function that returns a configuration object that is passed to Node's http.request(...), allowing you to configure TLS if so you need.
You can refer to this test case:
https://github.com/cometd/cometd-nodejs-client/blob/1.3.0/test/https.js#L53
I am also seeing a similar issue when using CometD and CometD Client packages to connect to Genesys.
I have a nodejs server that adds all the /meta/handshake, /meta/connect, /meta/disconnect... listeners. When I try to trigger the /meta/handshake I seeing SSL self signed certificate in certificate chain error. As a solution, I tried to install the ssl certificates on my server and tried to connect to Genesys but I still see the same self signed certificate error.
Is there a way to configure the listeners with rejectUnauthorized: false?
I have some opensource project, that has WebUI based on NodeJS. When I want to access it I can observe this logs in WebUI:
error: httpsServer Exception: on clientError:Error:
140446233978688:error:14094416:SSL routines:ssl3_read_bytes:sslv3
alert certificate unknown:s3_pkt.c:1487:SSL alert number 46 Aug 19
11:49:41 node[18614]: 140446233978688:error:140940E5:SSL
routines:ssl3_read_bytes:ssl handshake failure:s3_pkt.c:1210:
This issue observed only using Google Chrome (Using Firefox or Safari didn't generate this exceptions in logs). All browsers marked self-signed root certificate as invalid. My question - How can I make WebUI to ignore this exceptions? This WebUI only accessible from local net and I don't want to sign certificates for money. Thanks.
You cannot ignore this exception in your application since the problem is not caused by the application itself. Instead this alert is generated by the browser during the TLS handshake: the browser tells the server this way that it will not accept the certificate sent by the server. After this alert is sent the browser will close the connection. Even if you somehow ignore this exception in your node.js code you will not able to communicate with the browser - because it is the browser which is refusing the communication.
The only way to fix this problem is to use a certificate trusted by the browser. In case of a self-signed certificate this means that you either have to import the certificate into the browser as trusted (in which case Subject Alternative Names in certificate must match the URL) or you add an explicit exception at the warning dialog you get when visiting the site.
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.
I am trying to configure an IIS website to require SSL client certificates. The website is set up in both IIS 6 and 7, though I am more interested in making it work for 7. I set the require client certificates property in IIS and it works fine when accessing the site through a web browser, but a Java-based client is having trouble accessing it.
I believe the problem is that IIS does not request a client certificate during the initial SSL handshake. Instead it negotiates a normal SSL connection, checks to see if the resource requires client certificates, and if it does it then initiates a new SSL handshake that requests a client certificate. IIS does this so support sites that only require the client certificates for certain resources. Even when the requirement is specified for the entire website, IIS still initiates two SSL handshakes. I want to force IIS to request the client certificate on the first SSL handshake, which will hopefully get things working for the client. (The client is developed by an external partner and I have virtually no knowledge of how it is set up and no access to its source code)
Has anyone dealt with this problem in IIS before?
Here's how I did this, on IIS 7.5:
Run the following in an admin command prompt: netsh http show sslcert
Save the output in a text file. Will look something like this:
IP:port : 0.0.0.0:443
Certificate Hash : [a hash value]
Application ID : {[a GUID]}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Create a batch file using that info:
netsh http show sslcert
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=[your cert hash from above] appid={[your GUID from above]} certstorename=MY verifyclientcertrevocation=enable VerifyRevocationWithCachedClientCertOnly=disable UsageCheck=Enable clientcertnegotiation=enable
netsh http show sslcert
(Yes, you have to delete and re-add; you can't just alter clientcertnegotiation in-place. That's why it's important to save the hash and GUID, so it knows what to re-add.)
Run that batch file, check for any errors, done.
Keep in mind that this setting is applied per-certificate, not per-server. So if you use multiple certs, or change/update your cert, you will have to do this again.
It took me a while to find this metabase setting. We were having this same problem with our client using the new certicom libraries. Since the discovery of the MITM attack arround SSL Renegotiation, the answer in alot of circles has been to hangup on renegotitation requests.
running the following cmd from \inetpub\adminscripts will force IIS to always request a client certificate.
For IIS 6:
cscript adsutil.vbs set \w3svc\siteID\SSLAlwaysNegoClientCert True
(So for the default website, cscript adsutil.vbs set \w3svc\1\SSLAlwaysNegoClientCert True)
Keep in mind that some clients Internet Explorer prompt for client certificates when it recieves that packet wether the client certificate is needed or not.
For IIS 7:
Save the following text to a file called "Enable_SSL_Renegotiate_Workaround.js"
var vdirObj=GetObject("IIS://localhost/W3svc/1");
// replace 1 on this line with the number of the web site you wish to configure
WScript.Echo("Value of SSLAlwaysNegoClientCert Before: " + vdirObj.SSLAlwaysNegoClientCert);
vdirObj.Put("SSLAlwaysNegoClientCert", true);
vdirObj.SetInfo();
WScript.Echo("Value of SSLAlwaysNegoClientCert After: " + vdirObj.SSLAlwaysNegoClientCert);
Run the following command from an elevated / administrator command prompt:
cscript.exe enable_ssl_renegotiate_workaround.js
(Jacked from the KB article for 977377)