Scribd
Upload
80 views2 pages

X509 Certificate - UNICORE - Lecture 2

X.509 certificates use asymmetric encryption with a key pair containing a private key and public key. The public key is published while the private key is kept secret by the owner. Anyone can encrypt messages with the public key, but only the private key owner can decrypt them. To get an X.509 certificate, the public key and owner information are signed by a Certificate Authority (CA) using the CA's private key. UNICORE uses X.509 certificates for authentication and encryption - clients present their certificate to servers, who verify the client's identity by checking the certificate signature against trusted CA certificates in a truststore.

Uploaded by

Salum Juma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
80 views2 pages

X509 Certificate - UNICORE - Lecture 2

X.509 certificates use asymmetric encryption with a key pair containing a private key and public key. The public key is published while the private key is kept secret by the owner. Anyone can encrypt messages with the public key, but only the private key owner can decrypt them. To get an X.509 certificate, the public key and owner information are signed by a Certificate Authority (CA) using the CA's private key. UNICORE uses X.509 certificates for authentication and encryption - clients present their certificate to servers, who verify the client's identity by checking the certificate signature against trusted CA certificates in a truststore.

Uploaded by

Salum Juma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

How does encryption with X.509 certificates work?

Most security mechanisms on a UNICORE Grid are based on X.509 certificates. For each
X.509 certificate, there is a pair of cryptographic keys, that fit each other. These keys can be
used to encrypt and decrypt messages: whatever has been encrypted with one of the keys can
only be decrypted with the other key - but the keys are not equal. This is why this type of
encryption is called ‘asymmetric’. Such an asymmetric pair of keys can be used in a public key
infrastructure (PKI): The trick is that one of the two keys, called the ‘public’ key is published
and therefore open to everyone, whereas the other key - called the ‘private’ key - is kept secret
by the owner of the key pair. In order to be able to keep the private key secret, it must be very
difficult to reconstruct or guess the private key by looking at the public key.
Everyone can use the public key to encrypt messages that only the owner of the private key
can read. And, equally important, the owner of the private key can prove that he owns the
private key by encrypting a meaningful message with it: everyone can use the public key to
decrypt the message and make sure that it is meaningful, but only the owner of the private key
can produce the encrypted message. Asymmetric encryption can also be used for digitally
signing documents. With a digital signature, a person can prove that he really is the author of
a document, or that he approves the content of a document. The most common way of creating
digital signatures comprises two steps: first, a checksum for the document to be signed is
computed. The checksum is a relatively short sequence of characters (compared to the
document). It is computed by applying a well-known checksum function that always generates
the same checksum as long as the content of the document is unchanged. Second, the checksum
is encrypted with a private key. The encrypted checksum is published together with the
document and forms the digital signature. A reader of the document can use it for checking
whether the document was changed. To this end, he applies the same checksum function to the
document and compares the result to the checksum that he obtains by decrypting the digital
signature (using the public key).
In order to obtain an X.509 certificate from a key pair, the public key is stored in a document,
together with some information about the certificate’s owner-to-be (e.g. name, email address,
organisation). This document is then digitally signed with the private key of a certificate
authority (CA), which means that the CA approves the creation of the certificate. This process
is called ‘issuing a certificate’. Everyone can use the CA’s public key to check, whether the
certificate has been signed by the CA.

How does UNICORE use X.509 certificates?


With X.509 certificates, UNICORE ensures two things: First, each client or server on the Grid
can attest that he is who he claims to be. He does so by presenting his certificate - which
contains the public key - and providing evidence that he knows the private key belonging to
this public key (by encrypting a previously defined message). Since private keys are kept
secret, he must be the owner of the certificate. Second, the public key is used to encrypt
messages that only the person knowing the private key (the owner of the certificate) can read.
This way an encrypted communication channel between different actors on the Grid is
established (by secretly sending a newly created key that can be used for both encryption and
decryption of additional messages). The protocol defining the details of establishing the
encrypted channel is called Transport Layer Security (TLS), a successor of the Secure Sockets
Layer (SSL).
3.3.3. What does this mean to the user?
Before accessing a UNICORE based Grid, each user needs to obtain a valid X.509 certificate
which is issued by one of the certificate authorities (CAs) that the UNICORE servers trust. The
client presents this certificate to the server whenever he is asked for authentication. The server
then checks whether it trusts the CA that issued the certificate. It does so by searching for the
CA’s certificate in a so-called ‘truststore’ i.e. a file that contains a list of trusted CAs'
certificates. If the CA’s certificate is found, it knows it can trust the client. Analogously, the
client checks whether it trusts the server. If both checks are successful, a communication
channel is created.
All private keys for certificates that the user may want to use on the Grid are stored in a special
file called ‘keystore’. The keystore is encrypted and secured by a passphrase that the user has
to remember. During first startup, the Rich Client can create a new keystore file. It is also
possible to reuse an existing keystore file. The list of trusted CAs is managed separately: users
can use a keystore file, a simple directory containing files in PEM encoding, or a trust directory
in OpenSSL format for this purpose.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy