I've been trying to configure play framework 2.5.8 to use keystore on custom location with custom purchased certificate. Configuration is as follows (under play section):
"server":{
"https":{
"keyStore": {
"path": "/Users/...some_path.../keystore.jks",
"type": "JKS",
"password": "some_pass"
}
}
Everything is local, path reachable, keystore in place.
However, I constantly get debug message:
[warn] p.c.s.s.DefaultSSLEngineProvider - Using generated key with self signed certificate for HTTPS. This should not be used in production.
Keystore is prepared properly since everything works just fine if I supply keystore and password params as JVM arguments.
Is there anything else that needs to be configured? I even C/P-ed with slight modifications
def createSSLContext(applicationProvider: ApplicationProvider): SSLContext
method from DefaultSSLEngineProvider for testing purposes into one of my controllers to see if execution will reach line 44 (logger.debug("Using HTTPS keystore at " + file.getAbsolutePath)) which shouldn't happen in case of wrong configuration, weird keystore file, etc. To my surprise, everything worked properly. However, why Play isn't taking into account configuration from application.conf is beyond me. Unfortunately, supplying keystore params through JVM params is not an option for me in this particular scenario.
Related
I've been doing performance testing using Gatling and now need to find a way to add keyStore and trustStore to my requests. Was wondering if that is something I can add in the HttpProtocolBuilder or do I have to take a slightly different approach.
Basically is there a Gatling equivalent to the following RestAssured commands?
given()
.keyStore("src/test/resources/fooKeyStore.jks","fooPassword")
.trustStore("src/test/resources/fooTrustStore.jks","fooPassword")
Was wondering if that is something I can add in the HttpProtocolBuilder
There, you can only use perUserKeyManagerFactory to create a distinct KeyManager for each virtual user. This should be the way to go only if you want to provide different keystores for each virtual user.
You can define the default keystore in gatling.conf.
I recommend you let the default trusty TrustManager: you want to run a load test, not secure an application.
I am new to this OPC-UA world and Eclipse Milo.
I do not understand how the security works here,
Discussing about client-example provided by eclipse-milo
I see few properties of security being used to connect to the OPCUA Server:
SecurityPolicy,
MessageSecurityMode,
clientCertificate,
clientKeyPair,
setIdentityProvider,
How the above configurations are linked with each other?
I was trying to run client-examples -> BrowseNodeExample.
This example internally runs the ExampleServer.
ExampleServer is configured to run with Anonymous and UsernamePassword Provider. It is also bound to accept SecurityPolicy.None, Basic128Rsa15, Basic256, Basic256Sha256 with MessageSecurityMode as SignandEncrypt except for SecurityPolicy.None where MessageSecurityMode is None too.
The problem is with AnonymousProvider I could connect to the server with all SecurtiyPolicy and MessageSecurityMode pair mentioned above (without client certificates provided).
But I could not do the same for UsernameProvider, For UsernameProvider only SecurityPolicy MessageSecurityMode pair with None runs successfully.
All others pairs throw security checks failed exception (when certificate provided) else user access denied (when client certificate not provided). How to make this work?
Lastly, It would be really nice if someone could point me to proper User documentation for Eclipse Milo. Since I could not see any documentation except examples codes, and they are not documented.
SecurityPolicy and MessageSecurityMode go hand-in-hand. The security policy dictates the set of algorithms that will be used for signatures and encryption, if any. The message security mode determines whether the messages will be signed, signed and encrypted, or neither in the case where no security is used.
clientCertificate and clientKeyPair must be configured if you plan to use security. You can't use encryption or signatures if you don't have a certificate and private key, after all.
IdentityProvider used to provide the credentials that identify the user of the session, if any.
When the ExampleServer starts up it logs that its using a temporary security directory, something like this: security temp dir: /var/folders/z5/n2r_tpbn5wd_2kf6jh5kn9_40000gn/T/security. When a client connects using any kind of security its certificate is not initially trusted by the server, resulting in the Bad_SecurityChecksFailed errors you're seeing. Inside this directory you'll find a folder rejected where rejected client certificates are stored. If you move the certificate(s) to the trusted folder the client should then be able to connect using security.
Server: Windows Server 2012
Cold Fusion: 9,0,1,274733
Update-Level: hf901-00011.jar
Running on java version: 1.7.0_79
Java home points to the right path.
All certificates (for live and sandbox) are imported into the keystore of this JDK 1.7.0_79. I've tested it and renaming the cacerts file results in an error when connecting to the live API.
Testing the cacerts file using the keytool shows that the apropriate certificates are properly imported.
A little order app provides payment using PayPal.
First step is a connection to PayPal using the method "setExpressCheckout".
The connection to the live API using NVP at URL https://api-3t.paypal.com/nvp works and delivers the token URL-string.
The connection to the sandbox API using NVP at URL https://api-3t.sandbox.paypal.com/nvp fails with the error response:
I/O Exception: peer not authenticated
Connection Failure
Unable to determine MIME type of file.
Connection Failure. Status code unavailable.
Calling the URL https://api-3t.sandbox.paypal.com/nvp from the server works.
Test 1
imported the sandbox certificate for api-3t.sandbox.paypal.com
restart CF service
connection test failed with the same error
Test 2
renamed the cacerts file to cacerts.bak
copied the cacerts file from jre1.8.0_31\lib\security to the 1.7.0_79\lib\security
there is no specific PayPal cert in the cacerts file
restart the CF service
connection to live API works
connection to sandbox api fails with the same error
The weird thing is that the connection to the live api works without importing the specific certificate into the keystore when using the 1.8xx cacerts file.
I can't figure out why the connection to the sandbox fails. Maybe I can get new hints here?
If there are more informations needed please let me know. Thank you in advance.
Problem solved!
Scott Jibben (see his comment above) mentioned that the PayPal sandbox may already decline TLS1 connections in order to the upcoming change to do so in the PayPal live API.
This is absolutely right. But while in CF11 this isn't a problem because CF11 and its JRE are already using TLSv1.2, CF8-10 are using the default protocol of their JRE.
If not, one can force CF to use TLSv1.2 with the JVM argument
-Dhttps.protocols=TLSv1.2
Short:
CF8-10 are using TLSv1 while running with JDK1.70_79 and below no matter what the JVM startup argument -Dhttps.protocols was set to.
This is because the default protocol of these Java versions is TLSv1 and CF8-10 are simply ignoring the JVM startup argument -Dhttps.protocols and always use the JDK's default protocol.
This has changed with CF11 therefore it works fine with it.
Read detailed informations in a post from Wil Genovese at:
https://www.trunkful.com/index.cfm/2014/12/8/Preventing-SSLv3-Fallback-in-ColdFusion
What I did
I've installed the JDK1.8.0_144 and set up Cold Fusion 9 to use this one. Since then the connection to the PayPal sandbox API at api-3t.sandbox.paypal.com works pretty well.
Hope this may help others with this old and by now a little odd CF9.
I have changed the carbon.xml file and axis2.xml to point to my own key-store. But when I start the wso2-am, the log says:
WARN - ValidationResultPrinter The default keystore (wso2carbon.jks)
is currently being used. To maximize security when deploying to a
production environment, configure a new keystore with a unique
password in the production server profile.
Exmaple from axis2.xml
<KeyStore>
<Location>/data/wso2/certs/ibridge.jks</Location>
<Type>JKS</Type>
<Password>****</Password>
<KeyPassword>****</KeyPassword>
</KeyStore>
There will be 2 main reasons you to change keystore default password which is "wso2carbon".
When moving to production environments keystore should be altered
from the default of 'wso2carbon'.
When changing the default keystore.
You can learn how to do this by following this blog post.
Did you point your jks file in the secret-conf.properties file (AM_HOME\repository\conf\security)?
Did you specify wso2carbon as the alias when creating the KeyStore? When the server starts up it'll search for KeyStores having wso2carbon alias, and if it finds any, it'll assume the default keystore is being used. If this is the case try giving a different alias.
When trying to hit an environment with improperly configured SSL certificates, I get the following error:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:562)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
at dispatch.BlockingHttp$class.dispatch$BlockingHttp$$execute(Http.scala:45)
at dispatch.BlockingHttp$$anonfun$execute$1$$anonfun$apply$3.apply(Http.scala:58)
at dispatch.BlockingHttp$$anonfun$execute$1$$anonfun$apply$3.apply(Http.scala:58)
at scala.Option.getOrElse(Option.scala:108)
at dispatch.BlockingHttp$$anonfun$execute$1.apply(Http.scala:58)
at dispatch.Http.pack(Http.scala:25)
at dispatch.BlockingHttp$class.execute(Http.scala:53)
at dispatch.Http.execute(Http.scala:21)
at dispatch.HttpExecutor$class.x(executor.scala:36)
at dispatch.Http.x(Http.scala:21)
at dispatch.HttpExecutor$class.when(executor.scala:50)
at dispatch.Http.when(Http.scala:21)
at dispatch.HttpExecutor$class.apply(executor.scala:60)
at dispatch.Http.apply(Http.scala:21)
at com.secondmarket.cobra.lib.delegate.UsersBDTest.tdsGet(UsersBDTest.scala:130)
at com.secondmarket.cobra.lib.delegate.UsersBDTest.setup(UsersBDTest.scala:40)
I would like to ignore the certificates entirely.
Update: I understand the technical concerns regarding improperly configured SSL certs and the issue isn't with our boxes but a service we're using. It happens mostly on test boxes rather than prod/stg so we're investigating but needed something to test the APIs.
You can't 'ignore the certificates entirely' for the following reasons:
The problem in this case is that the client didn't even provide one.
If you don't want security why use SSL at all?
I have no doubt whatsoever that many, perhaps most, of these alleged workarounds 'for development' have 'leaked' into production. There is a significant risk of deploying an insecure system if you build an insecure system. If you don't build the insecurity in, you can't deploy it, so the risk vanishes.
The following was able to allow unsafe SSL certs.
Http.postData(url, payload).options(HttpOptions.allowUnsafeSSL,
HttpOptions.readTimeout(5000))
For the newest version of Dispatch (0.13.2), you can use the following to create an http client that accepts any certificate:
val myHttp = Http.withConfiguration(config => config.setAcceptAnyCertificate(true))
Then you can use it for GET requests like this:
myHttp(url("https://www.host.com/path").GET OK as.String)
(Modify accordingly for POST requests...)
I found this out here: Why does dispatch throw "java.net.ConnectException: General SSLEngine ..." and "unexpected status" exceptions for a particular URL?
And to create an Http client that does verify the certificates, I found some sample code here: https://kevinlocke.name/bits/2012/10/03/ssl-certificate-verification-in-dispatch-and-asynchttpclient/.