I am trying to configure a HTTPS Outbound connector that uses TLS v1.1 or v1.2. Not sure how to achieve that. I am running Mule Studio plugin within STS. Mule runtime is 3.6.2 EE.
I tried putting the tls-default.conf in resources folder, but get exception saying something like "Unsupported Cipher".
I have debug enabled and can see that the Handshake is using TLS V1
How can I make it use TLS v1.1 or v1.2?
You need to configure it at the connector level:
<https:connector name="https">
<spring:property name="sslType" value="TLSv1.2" />
</https:connector>
And reference the connector from you http outbound endpoint using connector-ref
Already answered in https://forums.mulesoft.com/questions/41012/getting-error-when-hitting-a-rest-api-via-https.html#answer-43960
Below is the answer I posted.
I resolved it in my system.
When it is not working in the Runtime that is attached in the Anypoint
studio then follow the below steps.
Navigate to the Anypoint studio installation directory
Search for "tls-default.conf" in the folder. This will show you all the files for all the Runtimes that you have installed.
there will be a property "enabledProtocols" make sure that it contains the TLSv1 in it as below
enabledProtocols=TLSv1,TLSv1.1,TLSv1.2
This above should apply to Cloud hub (Most of the times it is already
enabled) or on-premise systems.
It seems you might be affected by this issue. To check this, you can try using 3.6.4 EE which has the fix. You could also try using the HTTP module instead of the transport which is not affected by the issue.
Keep in mind that Studio had a bug where they launched the runtime without taking the tls-default.conf into account, so you will need to add the file in Studio to verify it there.
Another workaround could be adding the following system property -Dhttps.protocols=TLSv1.1,TLSv1.2. Both this and the tls configuration edit will affect all connections in a runtime.
Related
Forgive me if this question has been asked before, but searching for this issue hasn't turned up anything I can use. Most of the discussions are about enabling the port while I want to be able to disable it.
I have several legacy servers that are running Linux RHE 7 with Apache Mule 3.8 installed. Security insists that port 1099 be closed, which I gather is used by JMX. 3.8 is actually out of support now, but we still have it running on a number servers and they are reluctant to upgrade since they would have to make many changes to their own software.
Any suggestions would be appreciated.
PS. I don't actually work with Mule normally so my knowledge of it is limited to what I have picked up from having to upgrade the servers from time to time.
What I have found from searching around is that you can disable this in 3.9, with the following.
wrapper.java.additional.15=Xnoagent
wrapper.java.additional.16=-Dmule.agent.enabled=false
And this works fine on Mule 3.9 instances we have installed. However this doesn't work on Mule 3.8. I have tried a few other variations on this but nothing has worked yet.
That's not accurate. Mule doesn't activate port 1099 nor JMX by default. The configuration you mentioned works for all Mule 3.x releases. However it is for the Mule Management Console agent. Unless it's port has been set to something different in the file wrapper.conf the default port it uses is 7777. If it was changed to something else it should be in the wrapper.conf file.
If the port 1099 is actually used for JMX it has been configured in wrapper.conf using Java arguments. Review that file to find if there are any such Java parameters in there.
Another alternative is that some application is actually opening that port for something, like listening to inbound HTTP request. You would need to review each Mule application deployed in that Mule 3.8 server to understand that.
This is resulting from an outbound connection to Equifax's new TLS 1.2-enabled URL.
Background:
Servers: Windows 2012 R2, .NET 4.6.2, all TLS 1.x Enabled in Test, Stage and Production tiers per this. IIS configurations match between servers (app pools/code except tier-specific configurations/IIS settings.)
Servers are load balanced via Citrix Netscaler, but this site uses Port 80/HTTP, no HTTPS configuration.
Both tiers use the same Equifax URL, but with tier-specific credentials.
The Situation:
Prod will not communicate with their site, we get the opening error.
Our stage environment has no problem communicating.
What we have done:
- Validated TLS reg settings match
- Swapped the prod web.config to the Stage server and the communication worked, so it seems unlikely that it is a web.config issue in production.
- Validated .NET versions
- Checked LSA fips reg setting (set to 0)
- checked for wonky updates known to cause issues
We are going to setup a network trace, but for the moment we are at a bit of a loss. I would appreciate any insights as to what I might be missing.
Developers had to do the following:
Added the specification of using 4.6 per Microsoft recommendations.
Updated some other .NET references in the web.config to point specifically to 4.6.2
They made some changes in some older code pieces to make them 4.6.2-compliant.
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.
Recently I'm using TFS behind proxy authentication, everything works well till I try to install packages through the Package Manager Console, if I try to install a package, even if I set up proxy credentials to access TFS, the system asks for credentials to connect to nuget.org, when I input credentials, the authentication through nuget breaks the previous TFS proxy authentication, so I get the error HTTP code 407: Proxy Athentication Required (Forefront TMG requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )
After that I can't use nuget and can't use TFS so I have to restart VS2013, but in this way I can't install packages.
Any Idea??
Thanks
I worked around this issue with NuGet 2.8.50926.663 and a very restrictive company proxy by installing Fiddler2 from www.fiddlertool.com. It seems having some kind of proxy go-between helps NuGet play nicely with proxies.
Of course there are other tools which will achieve the same effect, e.g. WireShark or Privoxy. I know Fiddler is very useful on a development workstation, so I choose that.
Searching for other solutions kept coming back to issues and regressions of issues in older versions of NuGet, like version 1.5 for example. Seems like either the proxy authentication or HTTPS certificate handling of NuGet is not so streamlined.
I have a question about restricting the Admin Console access in version 4.0.3. I would like the admin console to be accessed only from the server in which WSO2 ESB is installed and not from the machines outside.
In tomcat I can do that using the address attribute of the Connector element in the server.xml
like this:
Connector port="8080" address="127.0.0.1"
The issue is I am not finding the server.xml within the 4.0.3 directory strcutre.
I found the file catalina-server.xml under wso2esb-4.5.0/repository/conf/tomcat in the latest version. I am not finding a similar file within 4.0.3 however.
Earlier it used mgt-transports.xml file for transport configurations in ESB_HOME/repository/conf. After the improvements for tomcat layer by adding it as a proper OSGi bundle in the new release tomcat configurations are offered directly to the user to adjust