Mule MMC Alert - Url Health check not working for HTTPS - mule

Im creating alert using URL Health check for HTTPS in mule MMC. When I configure Http url works fine. But for HTTPS how can I achieve the health check( https://apps:8089/check), since it is secured connection, there is no option for keystore path where can I place my certificate. Obvious Alert showing me 'SSL handshake error'( Because no where i can configure the certificate) .
How can I configure HTTPS url in MMC( MMC document in Mule also says for HTTP not for HTTPS). Hopefully some way should be there .
Let me know whether it is possible or not, If possible how to achieve the same.Help will be really appreciable.

I assume you are running MMC using container such as tomcat, glassfish or jboss. All these containers use JRE/JDK(depending on what you have configured). If you are trying to invoke an HTTPS url from MMC, the relevant certificate(for the HTTPS URL) must be imported into JDK/JRE trust store so that when HTTPS url within MMC is invoked in the JVM(that is running MMC in tomcat/glassfish/jboss), the relevant certificate can be recognized.
Download the certificate from the browser(by clicking on the green bar in browser)
Use this command to import certificate:-
keytool -import -file "Path to your certificate file" -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"
Once done, restart your container and try again.

Related

IIS SSL Certificate No longer visible from internet

Pulling my hair out here. Yesterday I set up an SSL Certificate in IIS10. This is the process I followed:
In IIS, under Server Certificates complete Create Certificate Request (generated server.csr & server.key)
Go to sslforfree.com and start "create certificate" process.
Enter Static IP in Domain box
In Validity, choose paste Existing CSR (paste in contents of server.csr)
Select free 90 day certificate
Choose HTTP file upload and add auth file to virtual share in IIS.
Verified OK.
Download certificate
Back in IIS, select "Complete Certificate Request"
Browse to and select "certificate.crt" file.
Give it a friendly name etc, and save.
Browse to website under sites in IIS, and select Bindings. Choose the IP of the server, the incoming Port, and the newly imported SSL certificate.
Back in sslforfree, check the installation.
Everything all good
So everything was working beautifully, could see the certificate in the browser etc, job done.
Now come to today, and the server is actively refusing requests. Go back to check the installation of my SSL on sslforfree, and it's no longer found. Tried removing and re-adding, but nothing I do seems to get the SSL to be visible.
It's not that the certificate is refused, the browser doesn't even think it's there. Why would IIS suddenly stop sharing the certificate? I am totally stumped.
EDIT
As per the advice below, I set up a DNS name with CloudFlare and pointed it at my server.
I Set up the bindings in IIS to link to the new hostname and removed the old certificate (one for port 443 and this one for port 4443 which the API runs on):
Ports 80, 443 and 4443 are all port-forwarded on the router to my server:
I then downloaded Win-ACME and successfully created the Let's Encrypt certificate, and the renewal task created in Task Scheduler.
SSL Cert now shows in Bindings:
SSL Certificate appears to be all good:
...but when I go to the site, using the new domain name. Same problem... no certificate:
So I'm not sure what the problem is here...
This issue may happens when the imported cert does not have a private key associated. solution would be to import the .CER file to your system(from where certificate is requested) personel store and export it with private key. Then copy the .pfx file to required server and import it from server certificate option under IIS.
And you can refer to this link: The Whole Story of "Server Certificate Disappears in IIS 7/7.5/8/8.5/10.0 After Installing It! Why!".
Thanks to Lex Li, I was able to dig around with Jexus Manager, and IIS Crypto to work out what was wrong.
Seems having TLS 1.2 an TLS 1.3 enabled on my machine at the same time was causing issues. Discovered this using Postman and disabling certain TLS Protocols, eventually getting it to work.
For those of you who may experience similar issues, using this application and setting it to "Best Practices" after disabling TLS 1.3 in my Registry, I finally have it working, with a certificate.

JMeter JMS samplers not attaching Client SSL certificate (self signed certificate)

I am running a JMS point to point sampler for TIBCO EMS queue testing. I have added all the tibco ems jars to jmeter lib folder. Configured the queue details, context factory, user credentials in JMS sampler.
When hitting the TIBCO ems with tcp request for queue, it is working. But while hitting with SSL url it is failing to connect.
I tried below way to attach the Self signed certificate given by tibco team
added the .pem file (only begin and end certificate) to JAVA JDK cacerts file and opened Jmeter in command line with -Djavax.net.ssl.keystore=cacerts with password. The SSL request failed to connect with tibco ems server
extracted the certificate from server through openssl -connect commands, copied the begin & end certificate sections to .cer file and used keytool to add them to trustore. Started jmeter with this truststore. the JMS sampler still failed.
I understand the SSL certificate is not getting attached with JMS sampler when we are running it. Can some one help out with steps to successfully attached the SSL certificate to the JMS request.enter image description here
Looking into Configuring EMS over SSL on Application Servers I think you need to provide the following Java System properties:
com.tibco.tibjms.naming.security_protocol=ssl
jsse.providerClass=com.ibm.jsse2.IBMJSSEProvider2
com.tibco.tibjms.ssl.expected_hostname=xxxx
com.tibco.tibjms.ssl.enable_verify_host_name=false
com.tibco.tibjms.ssl.enable_verify_host=false
com.tibco.tibjms.ssl.trusted=/path/to/your/certificate.pem
The properties can either be put into system.properties file (lives in "bin" folder of your JMeter installation) or passed via -D command-line arguments like:
jmeter -Dcom.tibco.tibjms.naming.security_protocol=ssl -Djsse.providerClass=com.ibm.jsse2.IBMJSSEProvider2 ....
References:
Java Secure Socket Extension (JSSE) Reference Guide
TibjmsContext
TibjmsSSL
Apache JMeter Properties Customization Guide
Overriding Properties Via The Command Line

Tomcat is not picking up the keystore

I am setting up the tomcat server which communicate with external system through SOAP web services(I am using the external system stubs and apache Axis2 library for that).
The external system is secured with ssl client/server authentication. The system provides me keystore file in .pfx format which contains two certificates.
Things I have tried:
I have extract those two certificates and added in my keystore. I added below entry in my tomcat/bin/catalina.bat file
set JAVA_OPTS = %JAVA_OPTS% -Djavax.net.ssl.trustStore=/pathtomykeystore/cacerts -Djavax.net.ssl.keyStore=/pathtomykeystore/cacerts -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.ssl.trustStorePassword=changeit
With above configuration my request fails with No X.509 client certificate HTTP header found in request.
I have enable ssl logs then I found that serverHelloDone is printed and after that it says
"No suitable client certificate could be found - continuing without
client authentication"
The same thing I have tried from SOAPUI Tool where I directly configure .pfx file as keystore and it is working fine there
The diff between Tomcat and SOPAUI logs is
SOAPUI can successfully competing Client authentication where tomcat is not.
also below lines are missing from tomcat ssl logs
keystore is:
keystoreType is: jks
keystore provider is
Update1:
I remove the keystore configuration from SOAPUI->project view-> WS Security Configuration -> keystore (This is working configuration) and added above mentioned JAVA_OPTS entries in soapui.bat file and now SOAPUI also giving a same error.
Anyone helps arround how soap ui pick and send the certificates from keystore configured in project view->keystore

Charles Proxy for Mobile apps that use SSL Pinning

Charles Proxy website comments that:
Note that some apps implement SSL certificate pinning which means they specifically validate the root certificate. Because the app is itself verifying the root certificate it will not accept Charles's certificate and will fail the connection. If you have successfully installed the Charles root SSL certificate and can browse SSL websites using SSL Proxying in Safari, but an app fails, then SSL Pinning is probably the issue.
Just to be certain, is it possible to use an HTTP monitor like Charles Proxy (or another monitor) even though a mobile app uses SSL certificate pinning?
As Steffen said you might need to patch the app to disable certificate pinning.
Most mobile apps don't use it though :) Thus you just need to enable SSL
connections with self-signed certificate. To allow that with Android
application do following. First Download apktool. Then unpack APK file
(according to apktool 2.4.1):
java -jar apktool.jar d app.apk
Modify AndroidManifest.xml by adding this attribute to application element:
android:networkSecurityConfig="#xml/network_security_config"
Create file res/xml/network_security_config.xml with following content:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config>
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>
Generate keys to sign APK:
keytool -genkey -alias keys -keystore keys -keyalg DSA
Build patched APK:
java -jar apktool.jar b app -o app_patched.apk --use-aapt2
Sign APK file:
jarsigner -verbose -keystore keys app_patched.apk keys
If necessary convert APK to JAR for further analysis: d2j-dex2jar.sh app.apk.
More information: Network security configuration.
Certificate pinning means that the application explicitly wants to get the original certificate. If you do have the original certificate and the associated private key (which usually means that the you control the server the application is using) then it is possible to be a man in the middle (i.e. HTTP monitor) even for applications using certificate pinning.
Of course your HTTP monitoring application must support specifying a fixed certificate. It looks to me like Charles Proxy does not support this. But mitmproxy supports providing a fixed certificate for specific domains.
If you don't have access to the expected certificate and the matching key then you cannot give the expected certificate to the application. The only hope is then to somehow disable the pinning in the application itself by somehow hacking the code. Use your favorite search engine and search for "bypass pinning android" or similar to get a variety of non-trivial ways how one can try to make the application believe that it got the expected certificate.

Coldfusion: CFHTTP with SSL encrypted Page (https://) - got an error

I'm making an cfhttp to connect to an encrypted page. Seems to work fine for some sites.
I/O Exception: Name in certificate `pro.test.com' does not match host name `go.test.com'
Is there a workaround to trust this certificate even if the host name doesn't match?
Think this is more Java question, and workaround should be affecting the JRE.
Not sure if this will work in your case, but possible solution is to import this certificate into the JRE keystore.
Generic description can be found at Sun website. Though process is pretty simple.
First you should navigate the needed HTTPS URL with your browser and export the cert using SSL properties (don't remember how it is done in IE, but in Firefox something like Security > View cert > Details > Save as -- still not sure because using non-English licalization), any X.509 type should work.
Next you should import it using keytool. Navigate to the current CF JRE's bin, execute the following command (replace arguments with your values) and restart CF:
keytool -keystore <path to keystore> -import -file <path to certificate> -alias <alias>
BTW, there is a UI tool for this, but I haven't used it so can't say if it works fine.
The sites that are probably working have a valid SSL Certificate from a trusted authority.
If you have control of pro.test.com, the preferred answer would be to get a valid cert for pro.test.com installed. But if that is not possible for some reason, I see two other options:
1) Do a try/catch where you try to connect via https, and fall back on http in the event of an SSL error. Obviously this would eliminate encryption for the failed connection.
or
2) Use Sergii's solution to import the key for that site into the Java keystore.
If go.test.com is just a development server, in that case you can create a self-signed certificate and import it into Java keystore. That way you can save up on cost by not paying to CA and get a quicker turnaround to resolve the issue