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
Related
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.
I have an issue after I installed the SSL Certificate in WorldClient, MDaemon 12.
I followed the link in installing the SSL, SSL installation was fine. Then, I followed the link to use the SSL in WorldClient. I use 888 for TCP port and 443 for https port.
When I call the webmail (http://mail.mydomain.com.sg:888) in browser, it opens properly. But, if https://mail.mydomain.com.sg:888, Secure Connection Failed error message is shown.
Any Ideas, please? Thanks.
I have solved this problem.
If you read all instruction from the link you given in your post carefully until finished, you'll get the answer.
Note: MDaemon will only display certificates that have private keys
using the Personal Information Exchange format (PKCS #12). If your
imported certificate does not appear in the list then you may need to
import a *.PEM file, which contains both a certificate key and private
key. Importing this file using the same process outlined above will
convert it to the PKCS #12 format.
You should make a PKCS#12 file from generating the (certificate) .csr and private key (.key) you have. If you on windows, install the openssl first on your PC. After successful generate the PKCS#12 file, follow the instruction again to install the SSL certification on MDaemon.
If you success, you'll see the certificate appear in the MDaemon.
Remember to restart your server or webserver to apply the changes.
Regards
I've got web application that uses authentification via LDAP. It works flawlessly, but production version is required to use SSL. We have a server running at "ldaps://ourserver.com:636", but Spring Security throws following exception when I try to connect to it:
Root exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested targe
Apache Directory Studio also warns me about unknown certificate, but allows to ignore the check it and eventually to connect and read the data required.
There are plenty of questions and answers here about how to implement LDAP over SSL, but no one of them provide full solution. I've got two opportunities: to make the certificate trusted or to disable certificate check at all. No matter which way I choose, I can't figure out how to use the mechanism with Spring Security:
If I choose to use keytool and make the certificate trusted, I can't figure out how JVM / Tomcat / Spring Security will figure out which password I have defined (-keypass changeit).
If I choose to disable the certificate validation, I can't figure out what is the place the code should be placed.
I'm also curious on how Apache Directory Studio is able to make the certificate trusted for itself without that keytool import - which significantly reduces application portability? Solution like that would be perfect for my webapp, but I haven't found anything like that all.
Here is a solution I was able to use. The key thing I had to understand is that neither JVM, nor container with webapp needs to know alias and password. It's JVM headache to check all the certs registered, and this has nothing to do with your webapp. Unfortunately, the solution implies that you install the certificate for the whole JVM. That makes webapp less portable, but at least it works correctly. I've decided to provide following bash script with the webapp sources so other developers can install the cert easily on their machines:
SERVER="mydomain:636"
CRT_NAME="mydomain.crt"
CRT_ALIAS="mydomain_cert"
echo -n | openssl s_client -connect $SERVER | sed -ne '/-BEGIN
CERTIFICATE-/,/-END CERTIFICATE-/p' > $CRT_NAME
$JAVA_HOME/bin/keytool -import -alias $CRT_ALIAS -keystore $JAVA_HOME/lib/security/cacerts -file $CRT_NAME -storepass changeit
You may wish to add additional error checks, I've omitted them to simplify the script. You will need root priviledges to launch the second command.
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
I keep getting this error when adding this. Any ideas. I worked on other WSDL links and they are fine except this.
org.apache.xmlbeans.XmlException: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
The WSDL is on https, so you need to add the domain certificate to your cacerts on JRE which comes with SOAPUI installation (also could be probably that wsdl is published also on http so you can try to change the url for wsdl to http, first try this if not try steps below).
You have to download the server certificate (you can connect with the browser to the url of wsdl and save the certificate as an archive).
Then you can import this cert to your cacerts with keytool:
keytool -import -alias somealias -file serverCertificate.cer -keystore SOAPUI_HOME/jre/lib/security/cacerts
(default password for cacerts is "changeit").
With this steps you can use the WSDL and avoid the "PKIX path building failed" exception.
Hope this helps,
The Problem with the SOAP UI is it's using it's won JRE to execute programs...
To resolve the above exception follow the below steps.
Export the certificate from the key store or browser (which contain the public key)
Go to the SOAPUI installed directory and locate following directory \SmartBear\soapUI-4.0.1\jre\lib\security
Import the certificate in to cacerts trust store (Which is the default trust store)
Restart the SOAP UI and load the WSDL...
This appears to be a bug in SoapUI (at least as of 4.6.4). I just ran into the same issue and after making sure I had all of the CA certificates imported everywhere I found this post that mentions the same problem.
I installed the nightly build as mentioned in the post and I was able to get past the SSL handshake issue.
There is a sly detail here:
The SOAPui calls wsimport command with an OS system call to wsimport program. It does not load internal class com.sun.tools.internal.ws.WsImportto do the WSDL import.
If you are running SOAPui with the default JRE that comes with it but you also have a different JDK installed, then when using SOAPui tools to generate code, the wsimport command used is the one the OS knows better from the PATH and not the com.sun.tools.internal.ws.WsImport that comes with SOAPui.
In this case the called wsimport will not references the embedded cacerts in SOAPUI_HOME\jre\lib\security .
Instead it utilizes the default cacerts of the JDK the wsimport belongs.
SOAPui uses wsimport from a JDK as this picture shows
In that case the steps you have to follow are:
Download and save the server´s certificate to a file, say srv-certificate.txt
Import this certificate to the cacerts of the JDK used by the SOAPui tools:
C:\>keytool -import -alias somealias -file cmq-certificates.txt -keystore C:\software\jdk1.8.0.65\jre\lib\security\cacerts
where jdk1.8.0.65 is the JDK used by the SOAPui tools.
Hope it helps!
I've had the same problem (working with profesionnal computer behind a corporate proxy) :
It appeared that I just had to set proxy in SoapUI to None to solve it (neither manual - cntlm, in my case - nor automatic - windows settings, corporate proxy - did work :-/) !...