How to Generate and Send Certificates and Validate Certificates with Servlets?

[Gokul Cj]

I want to generate a certificate from a servlet and use the certificate to authenticate the user to provide access to another Servlet API. How to generate certificates and send from server side and validate it in client side in java. Thanks in advance.

[Tim Holloway]

Welcome to the Ranch, Gokul!

I'm not sure what you are actually looking for. Certificates are not generally generated for short-term use in an application. For one thing, to be a credible certificate, a cert has to be vouched for by a trustworthy certificate authority.

What you are describing sounds more like a security token. Those are generated on-the-fly for a specific application's security needs and usually not applicable to other apps, although a more broad scope such as Kerberos can provide access control over a LAN.

In the open Internet, however, the way for 2 independent apps to grant each other security is via OAUTH2.

[Gokul Cj]

I have created a Java web application using servlet. I have developed a restful API from the servlet to access data from my website. In my application I have a admin and user login. Can I generate a self-signed certificate from the user login so that the user can use the certificate to access that API. The API(Servlet) should only allow the authenticated user to access the API. Instead of generating a random API token , I want to use certificate based authentication. Is this possible?

[Stephan van Hulst]

Sure it's possible, but as Tim points out it's pointless.

Why would you want to do this?

[Tim Holloway]

A Random API token and a custom cert are basically the same thing. Both are non-predictable bit sequences and have to be submitted as part of each authorized web API request.

[Gokul Cj]

Can you guide how to implement mutual X509 authentication at both server-side and client-side in servlets? I would like to try this certificate based authentication that's why I am asking.

[Stephan van Hulst]

There are many ways to do it. It depends on where in the application you want the authentication to take place, and how much of the code you want to write by hand.

I think you can configure most application containers to verify a client certificate before the request even hits your application. You can also add middleware to your application that filters the request when it reaches your application, but before it is routed to the final endpoint. Finally, you can call code to verify the client certificate from your request endpoint.

It's best to perform authentication as soon as possible, so usually you'd let the application container perform client authentication, and only defer it to your application's middleware if you need to do special stuff with the client certificate.

So really, even if this is a practice application, you need to tell us what application container you are using, what application framework you are using, and what you will be using the client certificate for.

[Gokul Cj]

I have developed a web application using servlet as server side language. I have made a separate API(servlet) for that application. The Application consists of a user login and a admin login. I want to generate a client certificate from user login. When the user accesses the API with the generated certificate the certificate should be validate to verify the identity of ther user. If the client certificate validation success, the user should be allowed to access the API else the access to API should be blocked.

This is the code that I have used to generate a X509 certificate.

import java.io.FileOutputStream;
import java.math.BigInteger;
import java.security.InvalidKeyException;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.NoSuchProviderException;
import java.security.SecureRandom;
import java.security.Security;
import java.security.SignatureException;
import java.security.cert.X509Certificate;
import java.util.Date;

import javax.security.auth.x500.X500Principal;

import org.bouncycastle.asn1.x509.BasicConstraints;
import org.bouncycastle.asn1.x509.ExtendedKeyUsage;
import org.bouncycastle.asn1.x509.GeneralName;
import org.bouncycastle.asn1.x509.GeneralNames;
import org.bouncycastle.asn1.x509.KeyPurposeId;
import org.bouncycastle.asn1.x509.KeyUsage;
import org.bouncycastle.asn1.x509.X509Extensions;
import org.bouncycastle.jce.X509Principal;
import org.bouncycastle.x509.X509V3CertificateGenerator;

public class Main {
  public static X509Certificate generateV3Certificate(KeyPair pair) throws InvalidKeyException,
      NoSuchProviderException, SignatureException {
    Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());

    X509V3CertificateGenerator certGen = new X509V3CertificateGenerator();

    certGen.setSerialNumber(BigInteger.valueOf(System.currentTimeMillis()));
    certGen.setIssuerDN(new X509Principal("CN=CBA"));
    certGen.setNotBefore(new Date(System.currentTimeMillis() - 10000));
    certGen.setNotAfter(new Date(System.currentTimeMillis() + 10000));
    certGen.setSubjectDN(new X509Principal("CN=Test Certificate"));
    certGen.setPublicKey(pair.getPublic());
    certGen.setSignatureAlgorithm("SHA256WithRSAEncryption");

    certGen.addExtension(X509Extensions.BasicConstraints, true, new BasicConstraints(false));
    certGen.addExtension(X509Extensions.KeyUsage, true, new KeyUsage(KeyUsage.digitalSignature
        | KeyUsage.keyEncipherment));
    certGen.addExtension(X509Extensions.ExtendedKeyUsage, true, new ExtendedKeyUsage(
        KeyPurposeId.id_kp_serverAuth));

    certGen.addExtension(X509Extensions.SubjectAlternativeName, false, new GeneralNames(
        new GeneralName(GeneralName.rfc822Name, "[e-mail]")));

    return certGen.generateX509Certificate(pair.getPrivate(), "BC");
  }

  public static void main(String[] args) throws Exception {
    Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());
    
    KeyPair pair = generateRSAKeyPair();
    X509Certificate cert = generateV3Certificate(pair);
    byte[] encoded = cert.getEncoded();
    try (FileOutputStream fos = new FileOutputStream("D:\\cert.crt")) {
        fos.write(encoded);
        //fos.close();      }
    cert.checkValidity(new Date());
    cert.verify(cert.getPublicKey());
  }
  public static KeyPair generateRSAKeyPair() throws Exception {
    KeyPairGenerator kpGen = KeyPairGenerator.getInstance("RSA", "BC");
    kpGen.initialize(1024, new SecureRandom());
    return kpGen.generateKeyPair();
  }
}

I have stored this certificate in crt file using FileOutput stream. I want to send this certificate while accessing the API. The certificate should be validated at the server-side. How to do validation at the serverside and what are the stuff I should check in the certificate for validation.

Server Used:
Apache Tomcat 9.0.62


How should I configure the server to prompt and ask for access for certificate while acessing API.


Can I test the authentication process in POSTMAN?

Please help me with this doubts. It would be great help for me to understand this. I am stuck at this for past one week and Thanks in Advance.

[Stephan van Hulst]

Do you have a separate web application that acts as the certificate authority, or does the application that hosts the web API also act as the authority that generates a client certificate when the client hits a login endpoint?

[Stephan van Hulst]

Gokul Cj wrote:Please help me with this doubts. It would be great help for me to understand this. I am stuck at this for past one week and Thanks in Advance.

Just to verify, this is just for practice, right? I really hope you're not using this to build production code.

[Gokul Cj]

I have two applications. One application acts as the Certificate Authority(for generating client certificate) and other application acts as WEB API.  I want to configure the Web api to validate the certificate. I am using this for pratice only.

[Stephan van Hulst]

First you must generate a certificate for your certificate authority (CA) and install it in the CA's key store. The public part of this certificate must be installed in the trust store of the other application (API), so that the API trusts the CA.

When the user successfully logs in with the CA, the CA generates a new short-lived certificate for the client, and signs the client certificate with the private key that belongs to the CA certificate.

When the client sends their certificate to the API, the API verifies the client certificate using the CA certificate that is installed in their trust store.

[Stephan van Hulst]

To impress on you how useless this is, the flow I described in my previous post involves the CA sending the client's newly generated private key to the client over a network.

A huge improvement would be for the client application to generate their own key pair, and send the public key to the CA when they log in. The CA then generates a signed certificate from the client's public key. That way, the client's private key never leaves their own system.

[Gokul Cj]

Can I use a self signed certificate for testing? If so what is flow for the authentication process?

[Stephan van Hulst]

You can use a self-signed certificate for the CA.

The client certificate is not self-signed: It is signed by the CA.

The authentication process is unchanged. The API simply verifies the client certificate using the CA certificate. That the CA certificate is self-signed will probably issue a warning when you install it in the API's trust store, but don't think it will cause problems when you verify the client certificate, as long as you realize that it is not safe practice in general to use self-signed certificates for anything other than testing and development.

Of course, this project should never move beyond testing and development, because as Tim said, the responsibilities of the CA include physically checking that the client is who they say they are before they generate the client certificate.

[Gokul Cj]

But the steps you mentioned can be done through JDK's keytool right?  but what if I want to do it programatically?

[Stephan van Hulst]

You use the key tool to generate the CA's key store and to import the CA's certificate into the API's trust store.

You use code in the client to generate the client's key pair.

You use code in the CA to generate and sign a client certificate from the client's public key.

You don't need code to verify the client certificate in the API. You can just let Tomcat do it.

If I'm interpreting the BouncyCastle API correctly, to generate a client certificate you set the certificate info using the following methods:

setSubjectDN() to set the client's distinguished name.

setPublicKey() to set the client's public key.

setNotBefore() and setNotAfter() to set the validity of the certificate. Keep the validity short, maybe a few hours or days.

setIssuerDN() to set the distinguished name of your CA. This must match the subject DN of the CA's own certificate.

Then, call generate() using the private key associated with the CA's certificate.

[Tim Holloway]

Please see my comments in your other thread: https://coderanch.com/t/752778/application-servers/enable-HTTPS-Apache-Tomcat#3494400


And let me repeat: If you create your own custom security system, it is almost guaranteed to be insecure. I'd say that well over 90% of the "genius-designed" security systems for webapps could be broken by non-technical personnel in under 15 minutes based on many years of experience. And horror.

Security is something best left to trained security experts and even then periodically exploits end up getting found. It should never be designed as an afterthought to application development.

[Gokul Cj]

Stephan van Hulst wrote:You use the key tool to generate the CA's key store and to import the CA's certificate into the API's trust store.

You use code in the client to generate the client's key pair.

You use code in the CA to generate and sign a client certificate from the client's public key.

You don't need code to verify the client certificate in the API. You can just let Tomcat do it.

If I'm interpreting the BouncyCastle API correctly, to generate a client certificate you set the certificate info using the following methods:

setSubjectDN() to set the client's distinguished name.

setPublicKey() to set the client's public key.

setNotBefore() and setNotAfter() to set the validity of the certificate. Keep the validity short, maybe a few hours or days.

setIssuerDN() to set the distinguished name of your CA. This must match the subject DN of the CA's own certificate.

Then, call generate() using the private key associated with the CA's certificate.

I need to add truststorefile and keystorefile in server.xml file of the tomcat server right?



And how this validation occurs internally. What parameters are checked by the server during validation?

And Thankyou so much for spending your time in explaining this.

[Stephan van Hulst]

The CA needs a key store and the API needs a trust store.

If both applications are running in the same server, I believe both can make use of the same file.

If you're using separate files for the key store and the trust store, you don't need to configure the key store in Tomcat because you're only using it programmatically, unless you want Tomcat to use the key store for HTTPS. But see Tim's comments about using a reverse proxy to handle HTTPS for you.

Gokul Cj wrote:And how this validation occurs internally. What parameters are checked by the server during validation?

At the very least, the server should check that the certificate hasn't expired or has been revoked, and it should verify the digital signature. It does that by retrieving the issuer certificate from the trust store whose distinguished name matches the issuer name on the client certificate. The issuer certificate contains the public key of the issuer who signed the client certificate. That public key is used to verify the signature on the client certificate. If the signature is valid, and the issuer certificate itself is also trusted and valid then by proxy the client certificate is trusted.

In theory the server could check other data that's inside the certificate, but I don't know what things Tomcat checks.

There is another step though. What stops an attacker from simply intercepting the client certificate and using it for itself? Well, an attacker doesn't have access to the private key that is associated with the client certificate. The server asks the client to encrypt some random data chosen by the server, and the server then decrypts that data using the public key to verify that the certificate really belongs to the client that is making the request.

[Tim Holloway]

Yes, multiple systems can use a shared keystore. It's really just an encrypted key/value store file, although I don't know about concurrency protections. Keystores are expected to be almost exclusively used read-only.

NOTE THAT a web client will NOT be using a Java keystore to hold its certs unless that web client is itself a Java app (and I won't swear to it even then). Apps like Edge, Chrome and Firefox each have their own proprietary places and formats to keep certs in.

[Gokul Cj]

Stephan van Hulst wrote:You use the key tool to generate the CA's key store and to import the CA's certificate into the API's trust store.

You use code in the client to generate the client's key pair.

You use code in the CA to generate and sign a client certificate from the client's public key.

You don't need code to verify the client certificate in the API. You can just let Tomcat do it.

If I'm interpreting the BouncyCastle API correctly, to generate a client certificate you set the certificate info using the following methods:

setSubjectDN() to set the client's distinguished name.

setPublicKey() to set the client's public key.

setNotBefore() and setNotAfter() to set the validity of the certificate. Keep the validity short, maybe a few hours or days.

setIssuerDN() to set the distinguished name of your CA. This must match the subject DN of the CA's own certificate.

Then, call generate() using the private key associated with the CA's certificate.

How can I get the private key from the CA's certificate?

[Ron McLeod]

Gokul Cj wrote:How can I get the private key from the CA's certificate?

You cannot - X509 certificates do not contain private keys.

[Stephan van Hulst]

You get the CA's private key from the key store.

Use KeyStore.getEntry() and cast the result to PrivateKeyEntry.

[Tim Holloway]

Tomcat's keystore contains both certs and private keys as generated by the certificate authority. The certs are what get sent by Tomcat to the client to authenticate the server. They are then used by the client to generate an encrypted response that is decoded via the private key. The private key must never leave the server. It's private. If it becomes public, then security is destroyed.

As I said, the Java keystore is an encrypted key/value store. It stores both certs and private keys.

[Gokul Cj]

Stephan van Hulst wrote:You use the key tool to generate the CA's key store and to import the CA's certificate into the API's trust store.

You use code in the client to generate the client's key pair.

You use code in the CA to generate and sign a client certificate from the client's public key.

You don't need code to verify the client certificate in the API. You can just let Tomcat do it.

If I'm interpreting the BouncyCastle API correctly, to generate a client certificate you set the certificate info using the following methods:

setSubjectDN() to set the client's distinguished name.

setPublicKey() to set the client's public key.

setNotBefore() and setNotAfter() to set the validity of the certificate. Keep the validity short, maybe a few hours or days.

setIssuerDN() to set the distinguished name of your CA. This must match the subject DN of the CA's own certificate.

Then, call generate() using the private key associated with the CA's certificate.

Can I use keyPair to setPublicKey() ?

I have tried the above steps and I sent a certificate in postman for testing the API but it allows access even without certificate. I have also made ssl configuratons in server.xml file of Tomcat but I do know where I have done the mistake.

[Ron McLeod]

Gokul Cj wrote:... I sent a certificate in postman for testing the API but it allows access even without certificate. I have also made ssl configuratons in server.xml file of Tomcat but I do know where I have done the mistake.

Did you configure Tomcat to request a certificate from the client: clientAuth="true" ?

You probably also need to configure the truststorefile to point to the keystore which contains the certificate  for the CA which signed the client certificate, or create another store which holds the CA's cert.

[Gokul Cj]

Ok

[Tim Holloway]

Ron McLeod wrote:
You probably also need to configure the truststorefile to point to the keystore which contains the certificate  for the CA which signed the client certificate, or create another store which holds the CA's cert.

Note that while I continue to maintain a dim view of this whole Rube Goldberg scheme, I want to do my part to at least keep people informed.

A keystore for a Tomcat host must contain a copy of the cert for that host and its associated private key as entries in the keystore. The keystore must ALSO contain the cert chain.

Let's say that I have a key and cert for mousetech.com. I got it from certme.org (a fictitious CA). The mousetech.com cert is chained to (and thus vouched by) the "serbia.certme.org" certificate. It is in turn chained to "licensedcerts.certme.org". Which is in turn is vouched for by "isrg.root.x1".

That's a chain of trust. The irsg.root.x1 cert is not contained in the keystore, however. It is a primary-level CA and its cert is built right into the Java Run Environment.

Every HTTP client and server application has some sort of top-level CA database built into it. The top-level CA is the ultimate authority. If you can't get a top-level CA to resolve, your entire chain of trust falls apart. There's only about a dozen or 3 top-level CA's and under normal circumstances, you'll never touch that list directly. As I said, those certs are part of the server (or JVM) itself.

In the case of a client-side cert, things do operate differently, since client certs are issued by the server and the only trust needed is that the host itself can trust that it issued that particular client cert.

[Gokul Cj]

Could you please show a demo and share it as drive link so that I could verify which step I have missed or what's wrong at my side? It will be helpful for me.

[Stephan van Hulst]

Gokul Cj wrote:Can I use keyPair to setPublicKey() ?

No. The problem with your original setup was that you created a certificate containing a public key by signing it with a private key from the same key pair. That's a self-signed certificate. The point of the CA is that it signs the client certificate using the CA's private key.

So, as I explained earlier, you must retrieve the CA's private key from the key store, and then use it to sign the public key that the client sent along with the login request.

[Gokul Cj]

Is there any possibility of verifying a self-signed certificate on the client's side?

I am bit confused in generating the certificate. Could you please show a demo and share it as drive link so that I could verify which step I have missed or what's wrong at my side? It will be helpful for me @Stephan Van Hulst ?.

[Stephan van Hulst]

All certificates can be verified. You just need to be aware of the kind of trust that is implied by such a verification.

Verifying the signature you've generated yourself, on a certificate you've generated yourself, that contains a key that you've generated yourself, tells you absolutely nothing other than that you trust yourself. It's meaningless and offers no real security.

Now tell me, what certificate do you want to verify, why do you want to verify it on the client side and what benefit do you hope to reap from all of this?

[Gokul Cj]

I am not expecting any benefits. I just want to understand and use it for personal use.

This is what I want to do

1) I want to create a root certificate and use it as CA(my own CA).
2) I want to create client certificates and I want to self-sign the certificates with that CA (using bouncy castle).
3) I want to allow the requests to the API whose client certs are self signed by my CA.

how to do this? What are the steps should I do?

Please Explain the each steps in a single reply.

[Stephan van Hulst]

Gokul Cj wrote:I just want to understand

Good.

and use it for personal use.

Not good. If you're going to use a project for anything beyond the learning process of writing the code, you need to make it in such a way that it can be used safely by anybody. "Proof of concept" projects have a habit of escaping the original purpose they were intended for. If you're gonna use certificates, use them properly.

This is what I want to do

...

Please Explain the each steps in a single reply.

We've already explained each step. There is no new information. If you want new information, you need to tell us what you don't understand about our previous explanations.

Also, you haven't told us yet what you meant by the following:

Is there any possibility of verifying a self-signed certificate on the client's side?

Why do you want to do this?

[Gokul Cj]

We've already explained each step. There is no new information. If you want new information, you need to tell us what you don't understand about our previous explanations.

I know you all have explained each step, but all your explanations are mixed, so I am confused about where to start? That's why I have asked to order your whole explanation in a single reply so that I could understand it easily.

Also, you haven't told us yet what you meant by:

Is there any possibility of verifying a self-signed certificate on the client's side?
Why do you want to do this?

And Sorry I asked this by mistake. I am going to sign the certs with my own CA so there is no need of self signed certs.

[Stephan van Hulst]

Stephan van Hulst wrote:You use the key tool to generate the CA's key store and to import the CA's certificate into the API's trust store.

Either generate a self-signed certificate for localhost to develop and test your application, or request a certificate from a reputable issuer like https://letsencrypt.org.

Put the private key that is associated with the certificate in your CA's key store, and put the certificate's trust chain in the API's trust store.

You can use openssl to generate the certificate for localhost, and you use the key tool to generate the key and trust stores.

[Stephan van Hulst]

Stephan van Hulst wrote:You use code in the client to generate the client's key pair.

You already know how to do this.

The client's key pair goes into their own key store. You can do this programmatically. The client's public key goes in a request to your CA to generate a client certificate. After the CA has authenticated your client, they generate a certificate programmatically. You've been shown how to do this.

[Stephan van Hulst]

Stephan van Hulst wrote:You don't need code to verify the client certificate in the API. You can just let Tomcat do it.

I believe Ron gave you some pointers on this.

[Stephan van Hulst]

Most of the things I told you about are relatively sane. The part of this that makes the whole setup objectionable is that the CA provides the client a certificate automatically upon request. Keep that in mind.