I know Java keystore stores DER encoded certificate and SSL communication works perfectly fine with it, I wanted to check what happens with PEM encoded certificate so I converted my DER encoded certificate to PEM encoded using openssl utility and then imported that PEM encoded SSL certificate into my keystore using keytool utility and below are outcomes:
PEM encoded certificate was successfully imported into my keystore and there was no exception.
Then I tried SSL communication using java.net.HttpURLConnection and it was also successful and there were no exceptions.
So, this basically suggests me that this works but I am not sure what are implications of the same and whether this is recommended or not to use PEM encoded certificates in Java keystore. I am looking for answers which through insight on the implications, pros and cons of using PEM encoded certificate in Java keystore.
P.S.: If someone is looking for openssl and keytool command I used then please let me know and I can provide.
Please note that I have already read this and this, and these doesn't answer my questions.
I generated my private key with openssl and it is file serverkey.pem, I have also serverreq.pem that I sent to cert authority. They will send me signed certificate.
Is there any way how to convert serverkey.pem into Java Key Store? Do I have to generate something else or does it need only private key serverkey.pem? Can I do it with Keytool?
I know how to import cacerts and the signed cert into existing JKS, but I don't know how to create JKS from private key PEM. Thanks for any help.
I want a server to validate a client through a certificate. I have the certificate user_cert.pem and the key user_cert.pkey stored locally.
How will i do an httpsURLconnection authenticating the client to the server?
I have searched, but i am a little bit confused. I found this link .
The problem is that my certificate is in *.pem format.
Should i set the KeyStore like this?
KeyStore ks = KeyStore.getInstance("PEM");
Sorry, if i give vague information, but i think there is not enough documentation.
I found a post describing
android supports certificates only in BKS Format and if we have certificates in PEM format, we should change them into BKS format through the Portecle GUI software.
I just ask for any source for information about client certificates in PEM format in android .
First thing first, your private key won't be private anymore if your application is distributed because it can be extracted from an APK easily.
80% of the code needed for using client certificates is in the official Android documentation (Unknown certificate authority).
Then, instead of the part with TrustManagerFactory, use a KeyManagerFactory and call sslContext.init(kmf.getKeyManagers(), null, null);.
FYI:
CRT/PEM is the same certificate format. Only the file extension changes.
BKS is the Android equivalent of JKS because JKS are not usable in Android.
I've built a Java app that exposes web-services to external authorized clients. The Web-services use WS-security with Certificate Authentication. Basically we act as custom Certificate Authority - we maintain a java truststore on our server and sign and add clients' certificate to it. Currently we have manual registration process that requires WS clients to upload their certificate signing request. We sign the CSR, add the certificate to our java truststore using keytool from the command line and return signed certificate along with our CA certificate to client. In turn clients use their private key to sign their soap message payload and embed signed certificate in the message. Server side decrypts the digital signature and verifies that the embedded certificate is signed and one matches our truststore before fulfilling client request.
Though little painful (because of manual labor) this setup is working fine. Now I've realized that our root CA certificate is about to expire soon and hence I'm looking to setup maintenance policy. how should I go about renewing the self-signed root CA certificate? Looks like I will have to create new and replace original. And that will impact all clients having to receive new certificate and import new CA certificate. Is that correct understanding or if there is better way to handle the situation?
If it matters, I have used openssl to generate original key-pair.
openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config openssl.cnf
Keeping the same private key on your root CA allows for all certificates to continue to validate successfully against the new root; all that's required of you is to trust the new root.
More info
I have a web app, which allows user to upload pkcs12. I store the pkcs12 as binary in database. Is there any way for me to know if the certificate in the pkcs12 is self signed or CA signed?
I am running a Java web app on tomcat and have openssl at my disposal.
Following email thread precisely tells the right way to verify if the base64 encoded certificate (i.e. PEM) is self signed or not: http://marc.info/?l=openssl-users&m=116177485311662&w=4
Following is the code snippet:
openssl verify -CAfile self_signed_cert.pem self_signed_cert.pem
should return:
self_signed_cert.pem: OK
OR compare the issuer and subject. If they are same, it is self signed
openssl x509 -in cert.pem -inform PEM -noout -subject -issuer
Edit: there are two better answers on this question today:
https://stackoverflow.com/a/57927684/377270
https://stackoverflow.com/a/14515875/377270
However, I think there's something more important to address -- why would one want to know about self-signed certificates. What's the goal? What problem is being solved? Probably trying to split certificates into two piles, self-signed and not-self-signed, is the wrong approach for most situations. The better approach is almost certainly going to be verifying that any given certificate has a valid signature chain from a trusted certificate authority, and that any connections associated with a given certificate matches the certificate.
Here's the rest of my original answer. It's probably not what you want.
It's a bit hacky, but the openssl x509 command can report both the issuer and the subject. If the subject and issuer are the same, it is self-signed; if they are different, then it was signed by a CA. (Strictly speaking, a great many self-signed certificates are also signed by a CA -- themselves.)
While testing this theory, I ran a handful of tests; it runs something like:
cd /etc/ssl/certs
for f in *.0 ; do openssl x509 -in $f -issuer | head -1 > /tmp/$f.issuer ; openssl x509 -in $f -subject | head -1 > /tmp/$f.subject ; done
cd /tmp
sed -i -e s/issuer=// *.issuer
sed -i -e s/subject=// *.subject
cd /etc/ssl/certs/
for f in *.0 ; do diff -u /tmp/$f.issuer /tmp/$f.subject ; done
Hope this helps.
The accepted answer here isn't strictly correct. Old question, but this is the first result in google for "how to tell if a certificate is self signed" so it needs to be cleared up.
A cert is almost always self-signed if the issuer and subject match, but it's not guaranteed. A certificate can be "self-issued" where it has the same issuer/subject but is signed by a private key that isn't paired with the public key in the cert.
The first part of the answer above from NitinB is the right way to check for a self-signed cert:
openssl verify -CAfile self_signed_cert.pem self_signed_cert.pem
"All self-signed certs are self-issued, but not all self-issued certs are self-signed."
Citation: https://www.rfc-editor.org/rfc/rfc5280
"Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations. Self- signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate."
Have you tried the BouncyCastle lib?
http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions
"
There are specific example programs for dealing with Attribute Certificates, PKCS12, SMIME and OpenPGP. They can be found in the packages:
org.bouncycastle.jce.examples
org.bouncycastle.mail.smime.examples
org.bouncycastle.openpgp.examples
Another useful source of examples is the test packages:
org.bouncycastle.crypto.test
org.bouncycastle.jce.provider.test
org.bouncycastle.cms.test
org.bouncycastle.mail.smime.test
org.bouncycastle.openpgp.test
org.bouncycastle.cert.test
org.bouncycastle.pkcs.test
org.bouncycastle.tsp.test
"
Java is unable to analyze PKCS12 so that you have to convert it to keystore using openssl.
Here the keystore has both private key and X509 certificate(or you can choose only to store certificate). Then get the issuer from keystore using standard JAVA API and manually verify issuer.
Details could be found in https://www.openssl.org/docs/man3.0/man3/X509_verify.html
X509_self_signed() checks whether certificate cert is self-signed. For success the issuer and subject names must match, the components of the authority key identifier (if present) must match the subject key identifier etc. The signature itself is actually verified only if verify_signature is 1, as for explicitly trusted certificates this verification is not worth the effort.