Within Apple's certificates page, if I select a payment processing certificate and then download the .cer file, can this .cer file be safely distributed to third parties without any security concerns? I am unsure of the specific purpose of this certificate file - but if this .cer file is all the information a third party has, can they do anything malicious with it?
The certificate is effectively a signed public key. It's used validate signatures from your private key, the fact the certificate is also signed by Apple attests to your status within their ecosystem.
You can distribute it without concern, in fact, it will be distributed to anyone wishing to verify you in this context.
.cer files can contain private key material, but shouldn't in this example.
Related
I have my own webpage www.kasperikoski.fi that is, the way I see it, trusted, and I would like to have the ability to digitally sign PDF-documents by using some kind of sertificate that is put into my webpage so that people really know that it is me signing all these documents.
At first I thought that maybe I could share "public key" at the bottom of my webpage, but then I heard something about OpenSSL. Could that be used in my needs?
How would you carry out this one so that I could use the PDF's integrated "sign digitally"-option?
Assuming that I read your question right, you want to let your web site visitors a way to download some documents, which are created or maintained by your web site, and you want those documents to be digitally signed.
If the document is pre-created, it's possible to sign it during creation (either with the tool that generates them, or create a separate piece of code for signing). If the documents are generated on-the-fly, then your web site should include signing capabilities.
To perform signing you need a certificate with a private key. But not every certificate would work. The certificate you need should be suitable for data signing, rather than just for SSL/TLS. You can try to obtain the certificate for your site from some CA and then use it for signing the documents. Whether the users' software would accept such certificates depends on how Key Usage and Extended Key Usage properties (extensions) of the certificate are put by the CA. Another option would be to create a self-signed certificate.
In case of a self-signed certificate you would want to place the certificate itself (without a private key) to your web site for the users to download and install. This is needed for validation of the signature in your signed documents. No need to say, that you don't put the private key to download, neither you provide it to your users by any other means. It's kept only on the server (and preferably secured to make stealing it harder for the possible attacker).
The technologies / components / tools to use in these scenarios depend on which of the above options you need.
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.
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.