The question may sound a bit stupid but I really want to know this.
When we download a file, say abc.exe, it is digitally signed with some digital certificate of some organisation. Why do we need to install that certificate? What is the use of it? What if we dont install it?
When I run certmgr.msc in my windows system, I see some certificates already installed. What do they mean?
If you get signed material, you may want to verify the signature.
Digital signatures usually are created using a private key and can be verified using the associated public key.
Certificates essentially are transport containers for public keys with some extra information. Thus, to verify signatures you usually need the certificate of the signer.
You install certificates to make them known to your system (to allow for signature verification) and to tell your system to trust material signed by the associated private key.
As having to install certificates by each and every party you want to trust is too much work, certificates can have hierarchies, some root certificate may be the issuer of multiple other certificates, and by trusting that root you implicitly trust those other certificates the root issued.
For more details you may want to ask on https://security.stackexchange.com/.
The RSA algorithm used for encryption is used for digital signatures.
Use of RSA for a signature is as under:
1. First, a message digest is calculated.
2. The private key is used to sign the digest of the message.
3. The signature is appended to the message and transmitted to the recipient.
4. The recipient calculates the digest of the received message.
5. Then, verifying the signature requires extracting the signature from the message
and using RSA on the signature with the public key.
6. If the result of the transformation and the newly calculated digest are equal, the signature is valid.
Related
Maybe it is an obvious question but I didn't find a clear answer to it.
The question is what uses to generate server certificate signature and how actually generation happens?
As far as I am concerned the certificate signature is server identity (as I understand it is information from fields in X.509 certificate structure) plus server certificate public key hashed with some hash-function and encrypted by private key of root certificate located on the CA.
Am I right? If for signature server identity is used, please clarify which exactly fields from X.509 are used because I am not sure that used all of them.
Thank you in advance.
what uses to generate server certificate signature and how actually generation happens
It is signed by the private key of the signer.
As far as I am concerned the certificate signature is server identity
No. It is proof that the signer has authenticated the certificate's subject.
(as I understand it is information from fields in X.509 certificate structure) plus server certificate public key those are hashed with some hash-function and encrypted by private key of root certificate located on the CA.
No. See above.
Am I right?
No.
If for signature server identity is used, please clarify which exactly fields from X.509 are used because I am not sure that used all of them.
The entire certificate is signed.
I'm reading about certificate-based authentication in SSL, and got a question about this process. (picture is taken from above link)
Question is: why server.cer and client.cer are not secrets. In this diagram, it seems that communication hasn't been encrypted when certs got exchanged, does this mean both certificates are exposed in plaintext? If so, why it's secure? Because in this way an adversary can easily obtain server's public key as well as its certificate, and impersonate the server. I think I misunderstood something. Please correct me.
Because in this way an adversary can easily obtain server's public key as well as its certificate
Correct.
and impersonate the server.
Incorrect. You need the private key as well as the certificate to impersonate the server.
The diagram you quoted isn't correct. Both sides will have not only a keystore but a truststore. The incoming certificates are checked against the local truststore; the outgoing certificate comes from the keystore.
given that the certificate is used to verify the public key belongs to the server
No. The certificate plus its digital signature is used to verify that the certificate belongs to the server. The digital signature is created with the private key. See the article you quoted.
However it isn't entirely correct. In the diagram, incoming certificates are checked against a local truststore, which is separate from the keystore. The session key is never exchanged (2.1 step 5).
So you decide to go with a CA like VeriSign (or whoever, doesn't matter for this question). You apply for an SSL certificate from them. This CA invesitgates you to make sure the information you provided in your application is truthful and that you are who you say you are. Finally, the CA grants you an SSL certificate.
I am really confused about CSRs, what they are, who issues them, who responds to them, and where/how they fit into the scenario described above:
Certificate-Signing Request: To me this means "A request to sign a certificate." So, who makes the request? Who signs it? Why is this necessary?
When is a CSR generated? When is it acted upon? What subsequent procedures/actions does the CSR hold up (while it is in the process of being signed)?
How does the CSR fit into the scenario described above?
Thanks in advance!
The name is confusing - it's not a certificate signing request but a request for certificate. When you need to acquire a certificate from the CA, you do the following:
On the client side you generate a keypair (a public and a private key). You save the private key in a safe place, and also you (your generator software) creates a certificate request usually in PKCS#10 format (there's one more format used, which is more rare). This request is a binary ASN.1 sequence of various fields which are filled by you and your software. The request also includes your public key.
Next the certificate request is sent to the CA (usually transmitted over HTTPS). The CA handles the request by parsing it and creating a certificate with your public key embodied. Some information provided in the request (mainly your name / organization name, called Subject Name) is copied to the certificate. The certificate is signed with CA's private key.
The procedure can be automated but normally should involve human validation as you will be required to provide identification information (company documents, your documents etc).
Finally you receive a signed certificate from the CA. You can combine it with the private key or you can keep them separated.
I'm creating a webpage to take sensitive customer information and wish this to be on an SSL secured page.
Ive been asked by a CA to provide a CSR.
I was planning to install OpenSSL on a server and create one of these.
Does this mean that the server I create the CSR on will be the same one I have to install the certificate they provide me or can I install it somewhere else?
What links the certificate they provide to the CSR I create?
Thanks for any help.
When a key pair (public and private) is generated, such as with OpenSSL, a CSR is also generated. The CSR is sort of a wrapper that contains your Organization info with the public key.
This is also the part of the pair where the CA will sign upon.
Once you have received the signed certificate (after paying companies like VeriSign, GoDaddy) you should be pairing the signed certificate back together with the initially generated private key and together they work in the app in which you wish to secure content transmission with. E.g. Web servers.
The key pair, and CSR files generated usually CAN BE moved to other hosts/servers. Only in cases where the key pair generation mechanism involves hardware (such as some nCipher devices) will you not be allowed to move to other machine.
It doesn't matter, where the certificate signing request (CSR) is being generated.
Just make sure, you keep the private key. Otherwise the issued certificate will be useless, as it's the key that "links" your CSR to the certificate.
We want to add automatic software updates to our application, but our company isn't yet ready to buy a code-signing certificate from a trusted root CA, so we'll be using a self-signed certificate to sign code updates (.exe and .dll) for now.
Question: how to verify a binary signed with a self-signed certificate, without having to install the certificate, using Microsoft's Cryptography API? The .cer file to check against will be bundled with the application. Or is it simpler to use a generic Crypto library?
You can skip the whole X509 thing, after all you don't really need it if you're going to be using your own certificates...
For what you want to do, first you have to generate your RSA private/public key pair. Then you store the public key in your application.
When you have an update, you sign it on your site, by getting the MD5 or SHA-1 or whatever hash you want to use; then you encrypt that hash with the private key. The installed applications fetch the update and the signature (the encrypted hash); when the application gets the binary file, it computes its hash, then decrypts the other one using the public key and compares them. If they're identical then it's a valid update, otherwise you reject it and warn the user or something.
With X509 certificates that are self-signed the mechanism is going to be exactly that, but the public key is going to have a bunch of additional data like the identity of the issuer which will be the same identity of the certificate.
I seem to recall hearing of a way to enable self-signed certs some years ago, back in the Win2k days, but it was very hacky, not at all suitable for public deployment and has probably been "fixed". If you do think about using some other crypto library, or developing your own, take care: it's very hard to distinguish good crypto from bad crypto.