ColdFusion CFHTTP and SSL Certs - ssl

Background: I have an ongoing problem with a Connection Failure error message when I try connecting to an API using CFHTTP. While reviewing the API in SoapUI I noticed there was a button SSL Info (3 certs) which is outlined below. When I click the button a window of copy pops up with the headlines outlined below.
"SSL Info (3 certs)"
CipherSuite:
PeerPrincipal
Peer Certificate 1:
Peer Certificate 2:
Peer Certificate 3:
I have a feeling these are the key to getting my application to connect and pull the JSON correctly.
Question: How or Where do I install this cert information. Should I copy all 310 lines in the window with the cert information and place it in new file and save it somewhere?
Any info would be great.

I have answered the question of installing certificates before. Here are the steps again to save you from searching...
If you are using cfhttp to connect via SSL (https) then the ColdFusion server definitely needs the certificate installed to successfully connect. Here is a previous answer that I gave on a similar issue:
Here are the steps you need to perform in order to install the certificate to the Java keystore for ColdFusion. First, be sure you are updating the correct cacerts file that ColdFusion is using. In case you have more than one JRE installed on that server. You can verify the JRE ColdFusion is using from the administrator under the 'System Information'. Look for the Java Home line.
The default truststore is the JRE's cacerts file. This file is typically located in the following places:
Server Configuration:
cf_root/runtime/jre/lib/security/cacerts
Multiserver/J2EE on JRun 4 Configuration:
jrun_root/jre/lib/security/cacerts
Sun JDK installation:
jdk_root/jre/lib/security/cacerts
Consult documentation for other J2EE application servers and JVMs
In order to install the certificate you need to first get a copy of the certificate. This can be done by using Internet Explorer. Note that different versions of Internet Explorer will behave slightly differently but should be very similar to these steps. For example, earlier versions of IE might save the certificate under a different tab than I mention.
Browse to the SSL URL in Internet Explorer - https://xyz/infoLookup.php?wsdl.
View the certificate by clicking on the lock icon and clicking view certificate
Then click the Install Certificate... button (note: if you do not see this button you must close IE and run it as administrator first)
Click on IE's Internet Options and click the Content tab
Click the Certificates button
Find the server's certificate under the Intermediate Certification Authorities tab, select the cert and click the Export... button
Export using DER format
Copy the exported certificate file to your ColdFusion server (you can delete the cert from IE if you want)
Run cmd prompt as administrator on the ColdFusion server
Make a backup of the original cacerts file in case you run into issues
The keytool is part of the Java SDK and can be found in the following places:
Server Configuration:
cf_root/runtime/bin/keytool
Multiserver/J2EE on JRun 4 Configuration:
jrun_root/jre/bin/keytool
Sun JDK installation:
jdk_root/bin/keytool
Consult documentation for other J2EE application servers and JVMs
To install the cert:
Change directory to your truststore's location (where the cacerts file is located)
Type this command (use current jvm and use current jvm's keytool) "c:\program files\java\jre7\bin\keytool" -import -v -alias your_cert_alias_name -file C:\wherever_you_saved_the_file\cert_file.cer -keystore cacerts -storepass changeit
Type yes at the prompt to "Trust this certificate?"
Note: your_cert_alias_name I used above can be whatever you want
Note: C:\wherever_you_saved_the_file\cert_file.cer change these values to whatever you use for the server folder and certificate file name
To verify the cert:
Type this command (use current jvm and use current jvm's keytool) "c:\program files\java\jre7\bin\keytool" -list -v -keystore cacerts -alias your_cert_alias_name -storepass changeit
Note: your_cert_alias_name use the same name here that you used above to install the cert
Restart the ColdFusion service It will not read the updated cacerts file until you do this.
You can delete the imported certificate file from the server if you wish.

Related

How to solve this error in my local machine?

Could not create script recorder - see log for details: >> keytool error: java.secuirity.KeyStoreException: jks not found <<
Command failed, code: 1
'keytool -genkeypair - alias : root_ca:-dname "CN= _JMeter Root for CA for recording (INSTALL ONLY IF IT S YOURS ), OU= Username: ujala , C=IN" -keyalg RSA -keystore proxyserver .jks -storepass {redacted}-keypass {redacted}-validity 7 - ext bc:c'
How to solve this error during the recording controller in JMeter???
If you properly installed JMeter and Java you should not see error like this, at least I have never faced anything similar.
The fact that keytool application cannot detect jks keystore type which is the default type indicates that something is wrong with your Java installation so I would recommend reinstalling JDK from scratch.
My expectation is that it should resolve your issue. If it doesn't - check whether you (or somebody else) amended any default Test Script Recorder certificate configuration. If the values differ from defaults - try reverting them (or even reinstalling JMeter)
Also be aware of an alternative way of recording a JMeter test: JMeter Chrome Extension, in this case you won't need to think about proxies and certificates

How to Solve Jenkins Plugins Installation Problem?

I am trying to install the version 2.162 of the open source Jenkins. The Jenkins successfully came up but, when I go to Manage Jenkins-> Manage Plugins, I see following error:
I've done some search and see this problem is regarding the certificate issue
There were errors checking the update sites: SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to > find valid certification path to requested target
In the keystore, which website certs should I add so that jenkins can donwload the plugins from?
I was able to solve this from Jenkins UI very easy to login to Jenkins with Admin
Manage Jenkins
Manage Plugins
Advance (Under the Manage Plugins)
Change URL from https to http and click on Submit
In the Last click on Check Now
You have to configure JENKINS update-site CA-s certificates in your JENKINS java store. Just get those certificates (you can get it from your browser accessing update-site URL) and add it to your java store (java store path: $JAVA_HOME/jre/lib/security/cacerts)
To fix this you need to download all the certificates used by all the sites related to the update plugin process in Jenkins.
Typically:
get.jenkins.io.cer
mirror.gruenehoelle.nl.cer
updates.jenkins.io.cer
There may be more. As you install a plugin. If it fails. Just repeat the process to download the certificate and add it to your keystore.
> Example: keytool -import -alias mirrorgruen -keystore
> $JAVA_HOME/jre/lib/security/cacerts -file ./mirror.gruenehoelle.nl.cer
This worked on MACOSx. Tip: Unless you've changed it. Use the default password of 'changeit' when prompted to type in your password.
Finally restart Jenkins - then attempt to install the plugins. That should turn the results green.
I think the answer here might solve your problem, sounds like the same issue:
Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?
You should have latest version of JDK.
I faced same issue and it was because while installing I used jdk1.8.0_241 instead of Java 2.91. And here I ended up in all kind of issues.
First I need to move to http from https (Solution above) and then still got same error while installing plugin.
To resolve this , you can see which Java version your Jenkins is referring, in your Jenkins installation HOME folder, under file named Jenkins.xml. Search for following line -
C:\Program Files\Java\jre1.8.0_291\bin\java.exe
if it is outdated, update it, JDK 1.8.291 worked like a charm for me !
This JIRA ticket helped me in getting to root cause of this -
https://issues.jenkins.io/browse/JENKINS-63515
I was using java version "1.8.0_91" when getting the SSL handshake error. Problem got solved after following instructions followed to upgrade Java to version 11
I downloaded jdk version 11.0.14 from https://www.oracle.com/java/technologies/downloads/#java11 and installed it
Also installed fontconfig using
yum install fontconfig
Modified below in /etc/init.d/jenkins with path of Java 11. Ex - /root/jdk-11.0.14/bin/java . Gave 755 permission to all folders and files in path /root/jdk-11.0.14/bin/java
Also configured update site in Jenkins configuration as
http://updates.jenkins-ci.org/update-center.json
If your problem is still not solved with above changes and if you are using a proxy where proxy is giving its own SSL certificate instead of original certficate of the website then below steps will be needed.
Add your HTTP proxy certificate (Get it from your IT team. Or access Jenkins update site in your laptop using same proxy and export certificate from browser as base64 cer file) to trusted certificates using below commands. Put the exported certificates in cer file in linux using vim. Make sure to give 755 permission for all folders and files in below paths so that jenkins user can read them.
CA cert paths
/root/jdk-11.0.14/jre/lib/security/cacerts
/root/jdk-11.0.14/lib/security/cacerts
keytool -import -noprompt -trustcacerts -alias proxy3 -file /root/proxy1.cer -keystore /root/jdk-11.0.14/lib/security/cacerts -storepass changeit -keypass changeit
keytool -import -noprompt -trustcacerts -alias jenkins3 -file /root/jenkins1.cer -keystore /root/jdk-11.0.14/lib/security/cacerts -storepass changeit -keypass change
configured /etc/sysconfig/jenkins with
ENKINS_HTTPS_KEYSTORE="/root/jdk-11.0.14/lib/security/cacerts"
JENKINS_HTTPS_KEYSTORE_PASSWORD="changeit"
Modified below in /etc/init.d/jenkins
candidates="
/root/jdk-11.0.14/bin/java
PARAMS="--logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war -Djavax.net.ssl.trustStore=/root/jdk-11.0.14/lib/security/cacerts"
Just a small hack. Update the URL in the file "hudson.model.UpdateCenter.xml" from https to http
<?xml version='1.1' encoding='UTF-8'?>
<sites>
<site>
<id>default</id>
<url>http://updates.jenkins.io/update-center.json</url>
</site>
</sites>

SSL Certificate Disappearing from IIS

This may seem like a duplicate of this and it kind of is but none of the solutions I tried worked for me! Here is the related Question:
Installed SSL certificate in certificate store, but it's not in IIS certificate list
My system is Windows 2016 running IIS 10. We issued a CSR file using IIS using *.mydomain.com (nothing in the Common Name, I think, because that will get named upon receiving GoDaddy's response). Our client went to GoDaddy.com, purchased a Wild Card certificate, and sent me a zip file with a .p7b and a .crt file. I installed the .p7b in the Intermediate Certificate section, per GD instructions. So now in the Certificate is in the Personal folder with info like 'issued to *.mydomain.com' and friendly name being 'gis.mydomain.com'.
But the Certificate does not have Private Key--and I think that's the problem: The Certificate disappears in IIS manager. When I try the certutil -repairstore command I get a prompt for a Card insertion.
Here is a fix I am thinking about: From the Certificate Enrollement Requests part of the console, export to a pfx file, then, using OpenSSL, make a PEM file. Then create a new pfx file to Import to IIS; problem is that the new pfx file creation gives me error "No Certificate Matches Private Key". Here is the command:
pkcs12 -export -in 1d4c26d43a4da203.crt -inkey my.pem -out final.pfx
Please note that Rekeying at GoDaddy may not help: Their .CRT file seems to be generated without the Private Key. Also, DigiCert is unable to find Private Key on the server even though the CSR file was created on the same server.
What are my options?
Thanks!
I fixed this issue by following the steps here:
https://www.namecheap.com/support/knowledgebase/article.aspx/9773/2238/ssl-disappears-from-the-certificate-list-on-windows-server/
Specifically, these steps:
Open Microsoft Management Console (MMC) as an Administrator. To open MMC, press Win+R combination, type in mmc and click OK.
Select Add/Remove Snap-in and choose Certificates and click Add.
Choose Computer account in the Certificates snap-in window, click Next.
Tick Local computer in the Select computer box, then click Finish.
Locate the certificate that was imported when completing the certificate request. The certificate should be in the Personal store. Note that the icon of the certificate next to the domain name does not have a key on it; that means that no private key is assigned to the certificate.
Double-click the certificate and go to Details tab.
In certificate details locate the Serial Number field, click on it and copy its value.
In a command prompt type: certutil -repairstore my Serial_number from the step above. Make sure the serial number of your certificate does not contain any spaces. It should be a single string of symbols.
You can now refresh the list of server certificates in IIS Manager to see the certificate. You may need to close and reopen IIS.
UPDATE
The certificate store name for Web Hosting is webHosting. Use this in place of "my" which is the Personal cert store.
If you have multiple certificates, you only need to run certutil -repairstore for the first one. Others install correctly via the Complete Certificate Request in IIS (ie, they do not disappear).
Nothing worked until I followed GoDaddy's instructions per https://www.godaddy.com/help/rekey-my-certificate-4976 and installed the Re-Keyed Certificate. I don't know what had happened to have caused the failure. I had followed the exact steps earlier but what the client provided did not work first time. My guess is that the CSR file was generated when the server machine was in some pending major Windows Update and after the Update the Private Key stored in the OS was somehow lost/inaccessible.
Oh well, moving on.
There is one more use case under which IIS server certificates gets disappear when we create the Custom CSR from MMC -> Advanced Operations -> Create Custom Request and choose the Enhanced Key Usage purpose as "Client Authentication" instead "Server Authentication" and since we are uploading the certificate to IIS under Server Certificates so it should be for "Server Authentication" to show up or not disappear on IIS -> Server Certificates
Fix -
Delete the certificate from MMC and make sure it is removed after
refreshing
Generate the CSR using MMC Custom Request option and Choose "Server
Authentication" in case of the purpose for key usage while
generating the CSR using the Custom Request Option from MMC
Generate the Cert and signed by CA for the CSR generated in Step-2
Complete the Certificate Request from IIS and certificate should be
available perfectly fine in MMC as well in IIS -> Server Certificate
This should work fine !
At last Fixed!!
Step 1 - Go to your servers IIS
Step 2 - Select your server and choose SSL Certificate from middle panel
Step 3 - From the action panel on the right choose "Create Certificate Request"
Step 4 - Fill in the necessary details (common name = domain name, rest not so important)
Step 5 - after completing the wizard you will be provided with a .CSR file open the file in notepad and CTRL-A CTRL-C.
Step 6 - Go to the product page of your godaddy account from there go to SSL and click manage.
Step 7(optional) - To check if everything's fine with your CSR file, In manage SSL page click "SSL Tools" and from there choose CSR Decoder, you'll be taken to a page where you can paste the CSR and if results are shown you are good move to step 8.
Step 8 - Go back to Step 6, choose your SSL linked to the DOMAIN.
Step 9 - From the SSL Dashboard once you scroll down a bit you'll see the REKEY option, click on it.
Step 10 - Paste the CSR texts in the space provided
Step 11 - Click "Add Change"
Step 12 - Scroll down, click "Submit All Changes"
Step 13 - After the SSL is reissued(5-10 MINS), download the zip files for IIS server.
Step 14 - That's it , you should be able to add the new .CES file into the IIS without it disappearing.
Let me know if this worked for everyone.
You need to convert the certificate to .pfx file and include your private key.
https://www.ssls.com/knowledgebase/how-to-install-an-ssl-on-a-windows-server-when-the-csr-was-generated-elsewhere/

soapui WSDL error when adding

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 :-/) !...

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