I have trouble with the HTTPS setup in Mule. I have tried both at work and at home with fresh Anypoint Installs. I have checked every StackOverflow posts every tutorial every blogposts but nothing is doing it. I have also tried EE and CE runtimes. I am using the lastest edition of Mule and also tried doing the HTTPS inbound endpoint but with the same result. This is a major part in my project and have just lost a day trying to figure this out and it's driving me crazy...
I am trying to use the self signed certificate at first but ultimately I would like to use an SSL certificate we purchased.
I put the JRE in the anypoint directory and also tried from Program Files JRE.
This is my first time doing SSL stuff so maybe I'm missing something but here goes :
I first go into my Jre bin directory using CMD in Admin mode.
I run this command as described in the HTTPS Transport Reference documentation:
keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks
I enter all the informations correctly and keep both passwords the same to simplify everything. The password is changeit.
I have also tried instead of FirstName LastName to enter the IP of my server I'm running my Anypoint on.
After having the keystore.jks, I copy it in my src/main/resources folder.
Here is my simplified flow in Mule. Normally I would then call a SOAP webservice or a REST webservice but I am trying to keep this the simplest possible :
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:tls="http://www.mulesoft.org/schema/mule/tls" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.6.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/tls http://www.mulesoft.org/schema/mule/tls/current/mule-tls.xsd">
<http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="localhost" port="8080" doc:name="HTTP Listener Configuration">
<tls:context>
<tls:key-store path="keystore.jks" password="changeit" keyPassword="changeit"/>
</tls:context>
</http:listener-config>
<flow name="omgHttpsPlzWorkFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
<set-payload value="#['Hello']" doc:name="Set Payload"/>
</flow>
</mule>
I then use DHC or Postman (Google Chrome Extensions) or the browser directly to call my listener https://localhost:8080/
I always get 500 or no response. In Chrome I get
Your connection is not private
Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
I tried adding loggers but nothing is showing up in the console.
I thought the problem could be with the ports or proxies at work but now I try from home with the same results.
I've tried putting port to 443 putting my ip as host. Adding truststores etc..Nothing is doing it. I think I am simply missing something very small and simple.
I hope someone can help me as this is the final step to my project and if it doesn't work I cannot deploy it as it contains sensible information that I want to be secured.
Thank you for your time
You are doing everything correctly. Just click on the link https://localhost:8080/ from your browser first so that you add the unsigned certificate to your local machine and everything will work fine. You can use Postman or DHC to access your service afterwards.
in Chrome click on Advanced -> Proceed to localhost (unsafe))
in Firefox click on I understand the risks -> Add Exception...
Related
I’m using Tomcat 9.0.19 and trying to enable X.509 cert.-based client authentication (AKA I&A) for a particular Web application.
In summary, the Tomcat works for an application that has basic I&A enabled over one-way TLS. When accessing the Web application that has certificate-based I&A, Tomcat does not seem to request a client certificate as part of the Server Hello message, prior to sending Server Hello Done and it later fails the authentication check:
02-Jan-2020 13:00:40.371 FINE [https-jsse-nio-443-exec-10] org.apache.catalina.authenticator.SSLAuthenticator.doAuthenticate Looking up certificates
02-Jan-2020 13:00:40.830 FINE [https-jsse-nio-443-exec-10] org.apache.catalina.authenticator.SSLAuthenticator.doAuthenticate No certificates included with this request
Traced the TLS flow in Wireshark and saw the TLS 1.2 handshake. Shortly after encrypted data is exchanged, the Tomcat sends an “Encrypted Alert” message and the socket is closed. Trying to contact the Tomcat from the browser, doing a GET. The browser does not prompt me to select a certificate, which also seems to point to Tomcat not requesting it from the browser.
Any help will be greatly appreciated!
More Details:
We have a set of certificates for the Tomcat and the client, issued by an Intermediate CA, which is signed (issued) by a Root CA. The trust stores have been setup on both sides (client and server) as well as key stores with the right certs/keys in them. The Web application is setup to require certificate I&A (web.xml):
<security-constraint>
<web-resource-collection>
<web-resource-name>All by default</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>OTService</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>certificate</realm-name>
</login-config>
The OTService role is setup in the Tomcat-Users.xml, along with a single user account:
Now, the Connector in server.xml is configured as follows:
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="100" SSLEnabled="true" scheme="https" secure="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="/apache-tomcat-9.0.19/conf/km/keyStore.jks"
certificateKeystorePassword="PASSWORD"
certificateKeyAlias="tomcat"
type="RSA" />
truststoreFile="/apache-tomcat-9.0.19/conf/km/trust_store.jks"
truststorePass="PASSWORD"
truststoreType="JKS"
certificateVerification="required"
clientAuth="true"
protocols="TLSv1.2"
</SSLHostConfig>
</Connector>
Any ideas why Tomcat would not request a client certificate?
The first issue that I discovered was that Tomcat ignored the Connector->SSLHostConfig settings for the trust store and used the JRE default trust store anyway. The way I discovered it was to have a browser save the negotiated TLS session key to a file (Google SSLKEYLOGFILE), then configured the Wireshark to use that file, captured the browser-Tomcat session and then was able to see every message in plaintext.
Next, I discovered that Tomcat was actually asking for a client cert., but the list of accepted Root CAs it was sending was from the default JRE cacerts file, not from the file specified by the truststoreFile attribute. Can have Tomcat use a different file across the board by adding a setenv.sh file to the Tomcat bin directory with Java properties to override default trust store location.
Now, I was in business, the browser was able to complete the TLS handshake, but then the authentication and authorization steps were failing. I finally determinate that the proper way to provide the cert. subject field in tomcat_users.xml file was not "CN=OU Client, OU=Control Systems, O=IoTOY, L=Scottsdale, S=AZ, C=US", but "CN=OU Client, OU=Control Systems, O=IoTOY, L=Scottsdale, ST=AZ, C=US". Finally, I had 2-way TLS working.
One thing to keep in mind is if anything running on the Tomcat attempts to connect over TLS to another system that uses commercial CA certs, it will fail because the truststore you're using now does not have commercial Root CAs' certs. One way to remediate it is to make a copy of the default JRE cacerts file and add your system-specific CA cert(s) to it and point to it from the setenv.sh file noted above.
When you have:
<Connector ...>
<SSLHostConfig>
<Certificate A=1 B=2 C=3 />
D=4 E=5 F=6
</SSLHostConfig>
</Connector>
then A,B,C are attributes of the Certificate object but D,E,F are NOT attributes of the SSLHostConfig object -- they are XML content which is different. Attributes need to be put IN THE TAG:
<Connector ... >
<SSLHostConfig certificateVerification="required" truststoreFile=... >
<Certificate ...keystore... />
</SSLHostConfig>
</Connector>
and that does cert-request on the initial handshake as desired (for me, tested on tomcat 9.0.14).
I have a requirement where soap based service needs to be consumed and in order to achieve that I had used WSConsumer component in Mule.
Where we give the service URL in the properties file and refer to it.
<ws:consumer-config name="Web_Service_Consumer" wsdlLocation="serviceApi.wsdl"
service="serviceAPI" port="serviceApiSoap12Port" serviceAddress="${serviceurl}"
doc:name="Web Service Consumer"/>
Now after the development we came to know that QA web service is a HTTPS web service and while hitting the service following exception is received
SSLHandshakeException: General SSLEngine problem
I'm able to hit the service with Http:request connector as following
<http:request-config name="HTTP_Request_Configuration" host="${host}" port="${port}"
doc:name="HTTP Request Configuration" protocol="HTTPS">
<tls:context>
<tls:trust-store insecure="true" />
</tls:context>
</http:request-config>
But the issue with above config is it won't work for HTTP configuration.
I should be able to connect to both HTTP & HTTPS as I have different environments.
Is there a way where I can achieve this with ws:consumer??
I assume the HTTP connector configuration shown is the one queried by your WS Consumer connector. A simple solution would be to configure the protocol of your HTTP config via property file but Mule doesn't play well with it because you may end-up with a TLS Context configured with HTTP and your connector won't work. There is a little trick you can do however: create 2 HTTP configurations - one for HTTP and one for HTTPS:
<http:listener-config name="HTTPS_Config"
protocol="HTTPS"
host="${host}"
port="${port}"
doc:name="HTTPS Config" >
<tls:context>
<tls:key-store type="${keystore.type}"
path="${keystore.path}"
keyPassword="${keystore.keyPassword}"
password="${keystore.password}"/>
</tls:context>
</http:listener-config>
<http:listener-config name="HTTP_Config"
host="${host}"
port="${port}"
doc:name="HTTP Config" >
</http:listener-config>
In a property file, define which configuration (i.e. which protocol) should be used:
host=localhost
port=443
protocol=HTTPS # or HTTP
And finally in your flow, use your property to reference the proper HTTP(S) config:
<flow name="http-testFlow">
<http:listener config-ref="${protocol}_Config" path="/test" doc:name="HTTP"/>
...
</flow>
The trick is to name your configuration ${protocol}_Config such as HTTP_Config and HTTPS_Config so the proper one is used at runtime via config-ref="${protocol}_Config". Mule will then dynamically use the proper configuration when your app is launched. This is entirely transparent for the user as only the protocol (HTTP vs. HTTPS) needs to be configured, and it can be used in any environment.
You can use this differently, the idea is to have Mule pick your HTTP or HTTPS dynamically at runtime.
EDIT: to configure your WS Consumer with HTTPS you'll need to reference a proper HTTP Requester Configuration such as:
<ws:consumer-config name="Web_Service_Consumer"
...
connectorConfig="HTTP_Request_Configuration"/>
<http:request-config name="HTTP_Request_Configuration"
...
<tls:context>
...
</tls:context>
...
/>
See Web Service Consumer documentation for details.
Note: though this solution works I would recommend using HTTPS all the time, for security reasons and to have less differences between your dev/QA/Prod/... environments - among other things.
I faced similar issues, we finally chose to have only an HTTPS config and define via property which keystore to use at runtime. In dev we would use a self-signed certificate and a proper keystore in environments requiring proper security.
Hope this helps.
I would like to have the ability to switch listener configuration easily in Mule (CE-3.6.1) from http to https (with basic autentication). I've created a variable in the mule-project.xml 'mule.protocol' and two properties files http.properties and https.properties with some data like port (the same port in http and https), host, password, etc.
in config.xml I have:
<context:property-placeholder location="${mule.protocol}.properties" />
<http:listener-config name="HTTP_Listener_Configuration" host="${host}" port="${port}" doc:name="HTTP Listener Configuration" protocol="${protocol}">
<tls:context>
<tls:key-store type="${keystore.type}" path="${keystore.path}" keyPassword="${keystore.keyPassword}" password="${keystore.password}" />
</tls:context>
</http:listener-config>
but I have two problems.
First, I get a message: Value '${protocol}' is not man-valid with respect to enumeration '[HTTP, HTTPS]'
and the second, section 'tls:context' is permitted only in https case, so I would have to hide it dynamically. How to solve these problems or whether there is another way to easily switch between the configuration of http and https? I'm using HTTP_Listener_Configuration in many services.
Unfortunately, this was only added for Mule 3.8.0 (coming soon). In older versions the protocol attribute does not support properties. You could use a Spring profile as a workaround. You can find more data in the JIRA ticket for this.
I have a Mule application which needs to talk an external server over HTTPS using 2 way SSL authentication.
My question is: How to enable Server Certificate verification in Mule ? It seems, by default Mule doesn't verify Server's Cert. I am using Mule v 3.3.0.
For example: '-k' option in curl disables server's cert verification.
In similar way, is there any configuration parameter by which I can enable/disable Server's cert verification ?
Thanks
Jai
For Mule versions before 3.6, the HTTP transport supports configuration of the trust store used by the HTTP outbound endpoint to determine whether the certificate presented by an HTTPS server should be trusted.
To provide a key store that contains the certificates of servers you need to trust, provide the <https:tls-server /> to the <https:connector />, and reference that connector in your <https:outbound-endpoint />:
<https:connector name="myHttpsConnector">
<https:tls-server path="truststore.jks" storePassword="supersecure" />
</https:connector>
<flow name="someFlow">
<https:outbound-endpoint host="remote-host" port="443" path="/api" connector-ref="myHttpsConnector" />
</flow>
The blog post linked in clare's answer explains this a bit, from both the server side and the client side. You can also refer to the HTTPS Transport Reference, although it doesn't explain the use of tls-server vs. tls-client.
You can check out this blogpost. It will show you how you can configure mutual authentication in Mule. HTH.
You can configure the HTTP Request connector in Mule >= 3.6.0 to use a trust store you create that contains the certificate(s) of the server(s) you need to trust using TLS Configuration.
It might look something like this:
<tls:context name="tlsContextForServiceFoo">
<tls:trust-store path="serviceFooServerCertificates.jks" password="supersecure"/>
<tls:key-store path="myClientCertificates.jks" keyPassword="extrasecure" password="ultrasecure"/>
</tls:context>
<http:request-config name="twoWayAuthServiceFooConfig"
protocol="HTTPS"
host="services.pentagon.gov"
port="443"
tlsContext-ref="tlsContextForServiceFoo" />
<flow name="useServiceFoo">
<http:request config-ref="twoWayAuthServiceFooConfig" path="/api/doStuff" method="POST" />
</flow>
I am having a problem with getting HTTP Basic auth. to work with Mule 3.2. We have earlier used Mule 2.1.1 without problems but now I am stuck. I have created a small test service with a configuration like this, based on examples in the Mule documentation:
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:vm="http://www.mulesoft.org/schema/mule/vm"
xmlns:mule-ss="http://www.mulesoft.org/schema/mule/spring-security"
xmlns:ss="http://www.springframework.org/schema/security"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.2/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/3.2/mule-http.xsd
http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/3.2/mule-vm.xsd
http://www.mulesoft.org/schema/mule/spring-security http://www.mulesoft.org/schema/mule/spring-security/3.2/mule-spring-security.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">
....
<spring:beans>
<ss:authentication-manager alias="authenticationManager">
<ss:authentication-provider>
<ss:user-service id="userService">
<ss:user name="ross" password="ross" authorities="ROLE_ADMIN"/>
<ss:user name="anon" password="anon" authorities="ROLE_ANON"/>
</ss:user-service>
</ss:authentication-provider>
</ss:authentication-manager>
</spring:beans>
<mule-ss:security-manager>
<mule-ss:delegate-security-provider name="memory-provider"
delegate-ref="authenticationManager"/>
</mule-ss:security-manager>
<model name="testModel">
<service name="testService">
<inbound>
<http:inbound-endpoint host="localhost" port="8888" exchange-pattern="request-response">
<mule-ss:http-security-filter realm="mule-realm"/>
</http:inbound-endpoint>
</inbound>
....
But when directing a browser to http://localhost:8888/ I just get an exception in the mule log:
Root Exception stack trace:
org.mule.api.security.UnauthorisedException: Registered authentication is set to com.computas.mt.mule.security.HttpBasicJBossAuthFilter but there was no security context on the session. Authentication denied on endpoint http://localhost:8888. Message payload is of type: String
at org.mule.transport.http.filters.HttpBasicAuthenticationFilter.authenticateInbound(HttpBasicAuthenticationFilter.java:160)
at org.mule.security.AbstractEndpointSecurityFilter.authenticate(AbstractEndpointSecurityFilter.java:58)
at org.mule.security.AbstractAuthenticationFilter.doFilter(AbstractAuthenticationFilter.java:56)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
I have checked the response headers, and all i get back from Mule is this. I would have expected to also get the headers that indicate that authentication is required:
Content-Type: text/plain
Content-Length: 243
Connection: close
401 Unauthorized
All works fine when not using authentication. Anyone else that have experienced this and found a solution? Maybe I have done a very simple and stupid mistake, but in that case i really can't see it...
Note: We run Mule inside JBoss 4.2.1, not standalone.
Regards
Jonas Heineson
When downgrading and using Mule 3.1.2 instead of 3.2.0 everything worked as expected. So there seem to be a bug in version 3.2.