Todor Kolev

Stephen, would the security mechanism that you suggest (each client generates their own private key) involve the client having to publish the matching public key, which will have to be installed on the server?

Also, isn't a private key relatively secure if it's encrypted by AES 256 bits?

I would like to point that I definitely agree about private keys being... private
But this client has zero abuse potential. Security here is more about preventing someone asking silly question before proper documentation is published.

The client will be published without any internal crypto. The server in question is a public server that anyone with $4.99 can request a valid client certificate for.
The API that the server exposes is read-only.
The resources that are being read are WHOIS data, which is available for free by any WHOIS site...

Just wanted to put things in the right context.
But also some really interesting discussion here that I take to heart!

Anyway, I will be done this weekend and I will show my code for the poor fellow who might just have a use case like mine!

Sorry for the late reply. I've amazingly managed to solve a really complex unrelated SSL issue (so proud!).
I've made pretty decent progress on this issue as well.

Just to clarify the context: The application being shared is a client. I want the client to work for all the intended recipients, therefore, I want to provide them the private keys which are used in client-side authentication.
Of course, I want to protect the private keys if the application somehow reaches an unintended recipient.
At this point, I should add that recipients are very trustworthy. They are not supposed to store that main password anywhere or provide it to someone else onwards. I guess that's still a possibility but, in the end, every vault is as secure as the people who can access it and therefore, every secret is liable to be made public.
Like, we can make a medical record be super tightly secured but a doctor has to read it at some point and they might choose to tell their husband about it and so on... I am just providing some protection here in case the laptop is stolen, etc...

As for storing everything in the same keystore - that's actually the first thought I had but there are a few complications:
A. As I was designing the class structure, I had the feeling that storing secrets in the keystore may incur added complications.
One feeling that I had is that you cannot refer to specific secrets in the keystore. I am still not sure how, if you store several certificates in the same keystore, you could refer to just one of them.
For example, when you are creating a socket using a keystore and the private key of a certificate in that keystore, you don't point to the exact certificate but just supply a password:
SSLContext context = SSLContexts.custom()                .loadKeyMaterial(keystore, pkPassword.toCharArray())
I imagine that what it is doing must be like: "try this password on all certificates and pop the first certificate that is deciphered correctly with this password.

B. My application has a use case for keeping several keystores with different certificates in each. I would not like certificates from one environment to be provided in the same keystore as certificates from another environment.
I realize this isn't how keystores and truststores work naturally.
For example, I know that I have ONE truststore for my browsing and when I want to authenticate a server, the browser will traverse all the CA certificates rather than have an exact path to the specific certificate...

Considering this one so far:
https://www.codejava.net/coding/file-encryption-and-decryption-simple-example

Will start this weekend. But if you have a better idea, would love to hear

I am providing my solution in the form of a java project, including the source (not just a compiled program).
There's no particular security concern here, since the whole product and my project (which does some additional stuff
with the product), as well as the infrastructure it's deployed on, will be made public for anyone to use.

Still, I think I should protect as much data as I can, and when things become public, we can look into un-protecting
anything we want.
Also, from a personal point of view, I am fascinated by the opportunity to do things this way. Definitely useful for
future projects!

The source makes use of some protected files and information:
- p12 keystore files (I need to deliver those with my solution)
- keystore passwords
- passwords to private keys inside the keystores

I am already aware of Hashicorp Vault and have used that successfully, but I don't think we deploy this into our
platforms and my needs are much more simple.

What I am currently doing:
-Dexecpass=myPassword

And this already provides pretty decent protection: All keystores are protected with the same password, which is
given to users via a secure channel and hopefully they don't stick a post-it note with it on their screen!

However, I am still not happy:
- Passwords to Private keys that are inside the protected keystores are hard-coded in an enum
- I am going to have a lot of keystores, private keys, etc...
- I am also thinking about issuing different passwords to users, to enable some form of repudiation

I want to avoid: -Dexecpass=myPassword -Dprvkpass1=myPrvKpass1, -Dpkrvpass2=myPrvKpass2, ...

I was thinking something like an encrypted file with all the passwords and ONE -Dexecpass=... will open everything.

What are some simple ways to write some java code that decrypts a file that I can distribute freely?

My Java program calls a webserver's REST API via HTTP(s)-POST
It uses client certificates and bearer token.

* From my Postman, using the crt/key files and the password for them, I am able to simulate that call and get the response expected.
* From the same machine, but using my Java program, I am referring to a pkcs12 keystore file, which contains a p12, which is a conversion of the crt/key files I have, but I am getting:

javax.net.ssl.SSLException: readHandshakeRecord
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1377)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:437)

I don't know where to look for more information about why is this happening.

Any ideas?

Wow, this was fascinating!
Thanks to all who contributed!

I ran the math and was able to encrypt, sign and see for myself why signatures work (in terms of: "why can't they be faked" and "why giving a message, encrypted with your holy-private-key, and also the plaintext message isn't compromising your private key").

I can go home now.

as I said, I understand asymmetric cryptography pretty OK (not great but OK).
Actually, I was taught that system when I was 9, by my math teacher, who
noticed I can tell if a big number is prime rather quickly.

But back to the subject of the post: my problem is that I don't understand how
RSA is applied to the signature element of a CA certificate, especially since,
from what I know so far, public keys are for encryption, and private keys are
for decryption.

I just read my own post and notice I am having a really bad communication day. I cannot actually talk to anyone, I can only write today and what I write also seems a little weird but I have no idea how to fix it.
Sorry if my post has caused anyone a headache!

I am pretty OK with private-public key stuff. Actually, in the company I work for,
I am the guy setting up new hires with their key pair and installing their public
key on the various servers on which our application is deployed on, so that they
can administer...

I am reading about certificates for a task I need to do. I've spent like 3 hours, reading
all sorts of google results and they all say more or less the following confusing thing:
"A website's certificate will have a signature from the CA.
The signature is a hash of the certificate details, encrypted using the CA's private key
The browser has a stash of known good public keys with which it can verify the signature"

I understand the problem: "how does the browser know that it's sending sensitive data to
the correct server and not some other server that somehow is also receiving the data?"

I understand what the solution does: "with certificates, the correct server is able to
prove that it is the intended address for the data, by providing a certificate that the
browser is able to verify.
Depending on the certification level, the certificate could proove that:
Lightest security: The server providing the certificate is operated by the domain owner
Stronger security: The server is operated by the organization it claims to be
Strongest security: Domain is owned by an org with the "right" (CA's criteria) to do so"

However:

1. How does the CA encrypt the signature hash with the private key? Wasn't the private
key for DEcryption?
2. How does the browser use the public keys to verify the signature?

I've seen those 3-tier diagrams about trust chain but I don't see how that answers my
questions. Especially since I am not sure what the arrows between the
end-intermediate-root entities mean.

I think I am confused between "encryption" and "signature" but no idea in what way
signature is different than encryption.

Perhaps you could write a few words about what happens to the signature in each step
in terms of private-public key operations?

Thanks for doing the digging I should have done! I'll try harder next time.

NB: It's such a pity that there is so much info out there that's outdated or just not tagged with the version that it applies to!

(javac 10.0.2)

I think I understand package structure in general but there is something in the fundamentals of this that works differently from what teachers say.
Here are some sources:

https://stackoverflow.com/questions/5921042/java-compiler-options-i-e-javac-d
"Similarly, if you don't specify any -d options, the class files will be put into directories according to the package structure, relative to the current directory."

Deitel & Deitel, Java: how to program:
"when a java file containing a package declaration is compiled, the resulting class file is placed in a directory specified by the declaration"

And it appears to be easy to find more sources that say the same...

However, let's look at my simple project:
* The following folder structure exists: ...\RootFolder\local\todor\sandbox
* RootFolder Contains file: LearnPackages.java
* LearnPackages.java has in the first line: 'package local.todor.sandbox;'

Now, when I am at RootFolder and do 'javac LearnPackages.java', there are no compilation errors or warnings and I get the LearnPackages.class file right in the RootFolder.
There is nothing in the RootFolder\local\todor\sandbox directory

Only when I do -d, does the compiler actually put the .class files where all the instructions I've seen say it will!

So, am I correct to assume there is a widely shared wrong understanding (or perhaps the behaviour changed between versions) and -d is used for BOTH specifying the "top level directory" ("Output Directory") AND telling to compiler to actually put class files in their package declaration folder?
Or I just don't understand the instructions?

PS: There seems to DEFINITELY be some difference since java7, where all the java7 instructions say that javac -d will NOT create the actual folder structure but my java9 instruction (D&D) says it will - and it does.

This is excellent, thank you!
I love this whole concept of "opinionated instance" - a pretty-well-thought-out model is something that I can subscribe to and feel confident to rely upon. It helps me to ignore the possibility that what I am doing may not be perfect.
It's part of my disability that prevented me from listening in school or doing anything constructive.
Basically, if no one put any limits on me, then I would buy lots of transistors and start there. Not saying I'd be good at that, just this will be my mindset!

I will have tons of fun this weekend!

I will post my project here and how to get started, for people who might stumble upon this thread.

Sorry to bump this but any help would be greatly appreciated! I am hoping to get started over the weekend.
Any word I can google in the right direction or maybe I am in the wrong section?
Or maybe you can suggest another place to look for help?

Thanks again

This usually is because of an infarction against the transport protocol.
I didn't look into your trace but if this is SOAP over TCP, the TCP protocol wasn't adhered to and one of the parties stopped the connection due to that and raised this exception.

Question: is this reproducible or happens sometimes?

Typically this could be:
1. Client or Server are shutting down too fast. Like, Server provides response and stops the connection rather than complete the protocol and shutdown properly.
2. Internet is unstable.

Try to put some delays around the program, see if this helps. The delays should give the parties enough time to finish the transfer.
Then you need to figure out if you implemented the protocol correctly, or you need better internet, or something else is wrong.

Good Luck!