I have a .Net SAML implementation that verifies assertions' signatures against a PKCS 7 certificate in a .p7b file.
I have a customer who have a Java based identity provider. They can only provide their certificate in a Java key store .jks file.
I can verify the assertions that their identity provider sends, but I can't check that those assertions were signed by a trusted provider without verifying them against the certificates in the Java key store.
I can find lots online on how to add a .p7b certificate to a .jks file, but nothing on how to reverse the process.
How do I get a .p7b certificate (that .Net and Windows can open) from a supplied .jks file?
Alternatively I'm loading the .p7b into .Net using the native X509Chain implementation. If I can't convert the .jks is there any way to load it in .Net in a way that lets me check the assertions' signatures?
It turns out that there is a command line utility in Java that do what I need. In the Java runtime directory (C:\Program Files (x86)\Java\jre7\bin on my machine) there is a utility called keytool (my newlines for readability):
>keytool -importkeystore
-srckeystore clientStore.jks -srcstoretype JKS
-destkeystore outputStore.p12 -deststoretype PKCS12
This produces an output store called outputStore.p12 that I can load in .Net with X509Certificate2Collection.Import()
Related
I am using SAP Commerce Cloud, in Public Cloud. And I am trying to insert a .cer file to make rest calls to API Gateway.
I read about importing it in java using command lines to import to keystore.
But, I don't know how to do it in the SAP Commerce Cloud
To install a certificate in a keystore. please follow the steps -
Create the keystore (if not created) using the below command
keytool -importkeystore -srckeystore /<path_to_the_pfx>/<pfx_name>.pfx -srcstoretype pkcs12 -destkeystore /<path_to_the_keystore_to_be_created>/<name_of_the_keystore>.jks -deststoretype JKS
You can control the keystore credentials as below:
a) sso.keystore.location - The path to the keystore (in this way the keystore can be repo managed)
b) sso.keystore.password - keystore password (default is changeit)
c) sso.keystore.privatekey.alias - Alias of the private key
Import the certificate using the below command
keytool -importcert -alias <alias_of_the_certificate> -file /<path_of_the_cert>/<name_of_the_cert>.cer -keystore /<path_to_the_keystore_to_be_created>/<name_of_the_keystore>.jks
To remind again, the keystore (with the installed certificate) can be repository controlled as well using the sso.keystore.location.
Alsternatively, if your question is to enable the REST calls from the Commerce cloud environment, please follow the steps mentioned here.
Hope this helps.
My Need is to accept the SSL certificate enabled on REST Webservice URL ( https:/:/dctm-rest) from standalone Java application(which will be bundled as JAR).
To my knowledge best way is to create KeyStore/TrustStore using Keytool, download the certificate from browser/openssl and add it to TrustStore.With this we are creating a dependency and someone has to keep on updating the certificate for every renewal.
Can someone guide me to get this implemented by removing the manual dependency?
You have to include the server certificate at https://dctm-rest into the whitelist of your JRE (the truststore)
Options
1) Include the server certificate in JRE trustore (jre/lib/security/cacerts) (Not recommended)
To download the server certificate, open site with browser, right-click on green lock, select 'view certificate' and download
The simplest way to explore cacerts and import trusted certificate is to use a GUI tool like portecle (http://portecle.sourceforge.net/). You can also use keytool
keytool -import -trustcacerts -keystore /opt/java/jre/lib/security/cacerts -alias mycert -noprompt -storepass changeit -file /tmp/examplecert.crt
See How to properly import a selfsigned certificate into Java keystore that is available to all Java applications by default?
2) Use your own truststore and include the server certificate (recommended)
System.setProperty ("javax.net.ssl.trustStore", path_to_your_trustore_jks_file);
System.setProperty ("javax.net.ssl.trustStorePassword", "password");
You can also create an SSLSocketFactory and add to your connection before connecting or apply to all connections using the static method
HttpsURLConnection.setDefaultSSLSocketFactory(sslFactory);
This is an example to create the socket factory
//Load JKS keystore that includes the server certificate or the root
KeyStore keyStore = ...
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(keyStore);
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, tmf.getTrustManagers(), null);
sslFactory = ctx.getSocketFactory();
3) Do not use truststore at all (Not recommended at all)
See Disable SSLHandshakeException for a single connection (I will not copy the solution)
I want to run some tests against an internal (with an internally minted cert) web service using SoapUI. I am not sure I fully grasp the SSL handshake stuff. But I exported the cert for the endpoint to a .cer file, then fired up java keytool with this command:
keytool -import -alias ca -file myservice.cer -keystore cacerts –storepass changeit
Which I got from another SO question. Then I added this truststore file (cacerts) to the project properties in SoapUI. But when I try to add a WSDL to the project, I still get the same error as before:
Error loading [https://myservice?wsdl]: 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
Am I completely off base? Do I add all the certs in the chain to the truststore? I wasn't able to do that, it told me that the alias was already in use? Or should I just get a cert minted from an outside trusted authority?
The SOAP UI raise the exception because your certificate not properly installed in SOAP UI trust store.
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...
To understand more about SSL ... follow the below link ...JSSE documentation
I am signing saml Response and assertion with x509 certificate. The response is posted to a java app, which throws error Signature length not correct…". I am asked to make sure that the xml doc is signed with certificate in JKS format and not pkcs12.
Is there a way to sign xml document in jks format in c# and then post the saml response to java app?
There is no such thing as a XML document signed in JKS format. These are apples and oranges.
XML digital signatures are specified in XMLDsig standard (assuming that you use XML digital signatures). http://www.w3.org/TR/xmldsig-core/
When you sign something you use the private key of an asymmetric key pair, probably an RSA key pair. http://en.wikipedia.org/wiki/RSA_%28algorithm%29
When you verify the signature you use the public key, commonly wrapped in an X.509 Certificate. http://en.wikipedia.org/wiki/Public_key_certificate
JKS and PKCS#12 are two different formats for storing the private key and the certificate in a container, encrypted using a password (since the private key is supposed to be private you want to protect it using a password).
When you sign an XML document you open the JKS/P12 keystore and use the private key to sign, and optionally include the certificate for easier verification for the recipient.
The private key and the certificate are identical in both cases, i.e. it does not matter if you use JKS or P12, the XML signature is bit for bit identical.
Probably you are sending both the XML document and the PKCS12 keystore to the recipient, and the recipient is unable to open PKCS12 keystore properly?
Java can open both JKS and PKCS12 with no problems at all, most likely your problem is related to something else than JKS vs PKCS12.
I do not know if C# can read and/or write JKS files (JKS == Java Key Store)
I noticed that in the keytool documentation it reads
"jarsigner [...] checks whether or not the public key of that certificate is 'trusted', i.e., is contained in the specified keystore."
whereas the jarsigner manpage states
"A keystore is not required when verifying [...]", and that the utility will always verify against the certificate supplied with the jar.
In the way I see it that would kind of defeat the purpose, since it would only certify that the jar was not altered since it was signed but not that it was signed by some specific authority/supplier.
Is there some way to make the verification fail if the certificate used to sign the jar is not known/trusted on the runtime system?
Or do I have to use a script to call
jarsigner -verify -verbose -keystore ...
and parse the output to see whether there is an entry for the signing certificate in the local (runtime) keystore?
Confused,
Peter
jarsigner utility is quite useless for JAR signature verification, as it does not verify the signer certificate, does not check trusted timestamps on the signature and does not provide usable result (parsing console output is not a good solution).
To avoid this limitations we have chosen to write our own verify_jar utility.