We Keep Coding

How to sign a certificate using BouncyCastle or Java 11

I've an existing certificate (C1), including private key, and not marked as a CA and trusted from an internal root-CA (C0)
I want to use it to:
Client side:
Generate a new keypair (C2)
Sign the keypair using C1, so that it has validation path C2<C1<C0
Use C2 to perform SSL client auth
Server side:
Accept the SSL client cert
Validate the chain regardless of C1 not being a CA
So far I've found articles on how to use a generic key to sign a new key:
Creating an X509 Certificate in Java without BouncyCastle?
However:
The resulting C2 is not trusted and thus not accepted when negotiating => We'll probably have to disable client cert validation on the apache side and perform it on the Java side
The above article hints at using private sun JDK methods: any hints on how to do that using standard jdk 11 classed or BouncyCastle?

As it is pointed out in comments by Boriss the Spider, certificate is not allowed to sign other certificates if any of the following conditions are not met:
Certificate subject must be CA via Basic Constraints certificate extension. See my blog post on how basic constraints work in practice and how certificate chaining engine reacts to violation.
Certificate must include certKeySign usage in Key Usage certificate extension
Validate the chain regardless of C1 not being a CA
it would be hard to disable basic constraints and key usage extension validation and retain other validation steps, this may require to disable client certificate validation at all. This is a simple PKI misuse that opens various vulnerabilities because you cannot implement proper certificate validation.

How to verify the incoming certificates from https with other certificates

Here I need to verify the SSL certificates for https websites with the root certificate. I have tried extremely lot but it could not be done yet. If anyone have any Idea to write such a code in java that could verify the Certs with the root cert. Mean that I have to check the certificate hierarchy signature validation for particular certs.
Thanks....

You need all root and sub root certs for validation. There is two different technologies; CLR and OCSP. OCSP is new one but some certificates support it.
You need some basic check for validate certifcate (also there are more rules):
Date is valid,
Certificate has ssl encription support, domain, etc,
Certificate issuer is correct,
Certifate rewoked or cancalled (with CRL or OCSP)
Java has own library for this, example: How to get server certificate chain then verify it's valid and trusted in Java

Certificate Path validation in Java including CRL validation

I have an intermediate certificate chain, a root certificate and a client certificate. I have to verify that they form a valid certificate chain together. This is working great when I have one intermediate certificate with a valid CRLDistributionPoint entry. The Java CertPathValidator API handles the validation beautifully.
My question was about the scenario when there will be multiple intermediate certificates and each of them might have a CRLDistributionPoint entry. Do I need to write additional code to handle this case? Or will Java simply validate against all CRLs? Or is it that the root certificate can delegate CRL Signing to just one certificate?
I tried searching online and could not find any clues. In addition to the answer to my question, it'd be great if someone could point me to a resource about PKI and certificates in general. Thank you!

No, you do not have to add code, the JDK implementation can smoothly handle the validation of a certificate path containing more than one intermediate CA certificates.
Note that the validation code is also tested against the PKI Test Suite from the NIST. That test suite tries to provide a comprehensive list of certificate and certificate path validation test cases.
If you want to look at the implementation code, you can look at the OpenJDK implementation : http://www.docjar.com/docs/api/sun/security/provider/certpath/package-index.html

What if trustStore certificate expires?

What excepttions I will/may recive if certificates stored in java trust store expires?
Will I certantly recive exception accessing certified resource? Under what circumstances there will be no exceptions?

If a certificate in the trust store expires, and is not replaces with an updated version with the same subject and key, it will be discarded for the purpose of building the certification path, so you'll get an javax.net.ssl.SSLHandshakeException (coming from "PKIX path building failed...").
If you look at the JSSE Reference Guide (trust manager section), it relies on the CertPath API (which implements what's needed to verify the date/time).
The default PKIX trust manager implements RFC 3280, which requires all certificates in the chain to be valid at the current date/time. See section 6.1:
The algorithm presented in this section validates the certificate with respect to the current date and time.
and
(d) for all x in {1, ..., n}, the certificate was valid at the time in question.
If you want to bypass this, you can implement your own trust manager (although it's generally not recommended, since you'd weaken the default algorithm).

I would expect an expired certificate to not be used by the system. So to your code, it should behave as though not found at all.

Any way of creating an Client Certificate programmatically for SSL Client-Auth without BouncyCastle?

I'm writing a server application that identifies it's clients by SSL-Client-Auth. Every Client should create it's own KeyPair and Certificate to connect to this server. Any unknown client (identified by a new public key) will be thread as a new client and registered with this public key. I don't want to sign client certs serverside (since this is would not increase security).
But it seems (after studing hundreds of pages) that I can't create the necessary files (or objects) programatically in plain Java, since the KeyStore would need at least self-signed client-certificates (which I can't create without BouncyCastle lib).
Am i wrong or is there really no way to do this?
And please provide me with a link or code. Java SSL semms to be VERY overcomplicated and has a bad documentation.

As far as I know, there is nothing in the JSSE API (including JSSE and JCE) to issue an X.509 certificate indeed. Dealing with the X.509 structures manually is actually quite complex, and you'd certainly need to read a lot more if you want to replicate what BouncyCastle does, without using BouncyCastle.
BouncyCastle is by far the most convenient way to achieve what you want. You could also use the sun.* packages (since keytool uses them to produce self-signed certificates), but using these packages is usually bad practice, since they're not part of the public JSSE API. They are not documented, rely on a specific implementation of the JSSE, and are subject to change. In contrast, BouncyCastle is meant to be used as a library.
I don't want to sign client certs serverside (since this is would not
increase security).
Since your server will only use the public key (and not the certificate) to perform the authentication (based on whatever mapping between public key and user you choose to implement), issuing the certificate on the server side or the client side doesn't matter in terms of security. The client could self-sign anything it wants, to the server can only rely on the public key anyway, not the rest of the certificate. The reason you'd need to "bundle" the public key into an X.509 certificate is because it's the only kind of client certificate supported (for example, the JSSE doesn't support OpenPGP certificates).
Having a service on your server that receives a public key and sends an X.509 certificate (with any dummy attributes, signed by any private key) might be the easiest option. In addition, if you use a mini CA internal to that server, this would simplify the way you'd need to tweak the trust managers to get the self-signed certificates through. (You'd still need to check the actual public key with your internal mapping, if you want to design such a security scheme.)