This week's book giveaway is in the Programmer Certification forum.
We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 and have Jeanne Boyarsky & Scott Selikoff on-line!
See this thread for details.
Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Confused about server certificates

 
Ranch Hand
Posts: 39
1
Python Java Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Todor Kolev
Ranch Hand
Posts: 39
1
Python Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since you seem to be OK with reading up on your own, search for public and private key pairs and asymmetric cryptography for the answers to your questions.
 
Todor Kolev
Ranch Hand
Posts: 39
1
Python Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Marshal
Posts: 14399
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you look at the diagram on the right side of the Wikipedia page, you'll see where Alice can sign a message with her private key and Bob can use Alice's public key to verify authenticity. I think that's essentially the same process with the certs that you're asking about.
 
Ranch Foreman
Posts: 53
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Todor Kolev wrote:"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"

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?


Well, seems there's some you don't know.

First: In a-symmetric crypto (or in crypto in general) there is no such thing as "encrypt plaintext" or "decrypt ciphertext" but only "perform the base operation" wich mostly boils down to some sort of "a^b mod c" (wich is true both for RSA and DSA - the difference is wich of those numbers is message and what's the key).
Hence: It doesn't matter with what kind of data and key you perform this data.

Second: Most systems use RSA - so I will limit my example to it. DSA works a bit different, but very similar.
In RSA you have a plain text, a cipher text, a public key and a private key. Further RSA is devided into encryption and signature. These go by this:

encryption:
encrypting data: plaintext message "m" is raised to the power of public exponent "e" and mod by shared modulus "N" -> c=m^e mod N
decrypting data: ciphertext "c" is raised to power of private exponent "d" and mod N -> m=c^d mod N

signature:
signing: hash of message "h" is raised to power of private exponent "d" and mod by shared modulus "N" -> s=h^d mod N
verify: signature "s" is raised to power of public exponent "e" and mod N and is then compared to calculated hash: h=s^e mod N

You see: RSA always use a^b mod c - the only what changes is the input base and the exponent. Data encryption and signing differs by what's used as exponent at what time.

In addition, signing uses a hash of the message instead of the message itself. Checking then works by comparing the hash you got after RSA operation with what was calculated over the message - if both match is pretty much sure, that integrity is proven (depend on collision resistance of hash function - hence SHA-1 shouldn't be used anymore as it's known for possible attacks).

Certificate validation works by calculating the hash of the certificate and compare it to whats in the signature - if they match the certificate is taken as valid.
Prove of validity is done when a valid path can be build to a trusted root certificate. Root certificate are a bit special as they what's called self-signed - so it's own private key is used to sign it's own public key instead of rely on a signature of a third party (CA).
 
Saloon Keeper
Posts: 10785
231
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The important thing that you're missing is that there are two things you can do with key pairs:

1) Encrypt and decrypt
2) Sign and verify

The private key is used to decrypt and to sign. The public key is used to encrypt and to verify.

When you want to send a private message and you only want the receiver to be able to read the message, you encrypt a message with the receiver's public key, so only they can decrypt it with their private key.

When you want to send a public statement (such as "I am coderanch.com!") and you want everybody to verify that the statement really was yours, you encrypt the statement with your private key, and everybody will be able to decrypt the statement and be certain that it came from you. After all, you're the only one who can make a statement that can be decrypted with your public key only.

Said in another way, when sending secret messages, the holder of the private key should be the only one who's able to READ the message. When sending signatures, the holder of the private key should be the only one who's able to WRITE the signature.
 
Todor Kolev
Ranch Hand
Posts: 39
1
Python Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kristina Hansen
Ranch Foreman
Posts: 53
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Be aware: A signature is meant to proof integrety. So, instead of sign the message itself (wich only works when the message is less than the keylength) the message is hashed. The "security" relies on colision resistence of the hash algorithm so it's hard to forge a hash for a manipulated message.
 
I like tacos! And this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!