What is a CSR?
CSR is an abbreviation of Certificate Signing Request. A digital certificate is in principle a public key that has been signed by a Certificate Authority (CA)
The public key fits together with a single private key. Both these keys consist of a long series of numbers that fit together mathematically.
If data is encrypted with one of the keys it can only be decrypted with the other.
The private key is private and should always be kept a closely guarded secret. The public key can freely be handed to anyone.
For a CA to be able to sign a certificate the requester first need to make a set of digital keys. One of the keys will be used as the private key while the other will be the public. The keys will be automatically created as part of the CSR generation. The specifics on how to generate a CSR varies depending on the circumstances (for further information see the technical guides or contact FairSSL)
After a key pair has been created a certificate signing request containing among other things the public key and information for identification of the requester can be made. The private key will not be attached but is instead used to sign the request before it's sent to the CA.
If the request is accepted by the CA, they will return a digital certificate that has been signed with their private key.
As long as you have the private key and the digital certificate containing the public kan it's possible to document who you are, sign documents, encrypt data etc.
Most Certificate Authorities choose to assign properties to their certificates.
Among these properties are the following:
You might already have a personal ID in form of "The Public Electronic Signature" (NemID) which you can get for free from the Danish Authorities. This certificate is used for communication with the public Denmark.
You can see guides for generating CSR on different servers here.
Back
The public key fits together with a single private key. Both these keys consist of a long series of numbers that fit together mathematically.
If data is encrypted with one of the keys it can only be decrypted with the other.
The private key is private and should always be kept a closely guarded secret. The public key can freely be handed to anyone.
For a CA to be able to sign a certificate the requester first need to make a set of digital keys. One of the keys will be used as the private key while the other will be the public. The keys will be automatically created as part of the CSR generation. The specifics on how to generate a CSR varies depending on the circumstances (for further information see the technical guides or contact FairSSL)
After a key pair has been created a certificate signing request containing among other things the public key and information for identification of the requester can be made. The private key will not be attached but is instead used to sign the request before it's sent to the CA.
If the request is accepted by the CA, they will return a digital certificate that has been signed with their private key.
As long as you have the private key and the digital certificate containing the public kan it's possible to document who you are, sign documents, encrypt data etc.
Most Certificate Authorities choose to assign properties to their certificates.
Among these properties are the following:
- Code Signing:
Used to sign programs, scripts and macros. - Server Signing:
Used to identify servers and encrypt data traffic - Client Signing :
Used as a personal ID and can often encrypt and sign documents and emails.
You might already have a personal ID in form of "The Public Electronic Signature" (NemID) which you can get for free from the Danish Authorities. This certificate is used for communication with the public Denmark.
You can see guides for generating CSR on different servers here.
