Certification Authority Management

In SPARTA all the FrameworkComponents (but not the user of course) act as a Certification Authority.

In order to create CAs and manage certificates we used openssl tools .
Official documentation:

Creation of Certification Authority (CA)

First of all, a generic CA usually owns a trusted certificate, that is preloaded in users browsers, or is trusted following a chain of certificates.

In this tutorial we are just going to create a “self signed” certificate.

With “self signed” we mean that the certificate is signed with the private key associated to the same public key in the certificate.

In other words, if we read the content of a self signed certificate we can notice that the Issuer and the Subject fields are identical.

To create a self signed certificate we have to run these commands:

  1. create a key pair:
    openssl genrsa -out myCA.key 2048
    openssl rsa -in myCA.key -pubout > myCA.pubkey
  1. create a self signed certificate:
    openssl req -new -x509 -key myCA.key -out myCA.pem -days 1000

Sign a certificate with the key of the CA

Generate a key for the certificate you are creating

openssl genrsa -out newcertificate.key 2048

Generate a request of certificate, with the public key just created

openssl req -new -key newcertificate.key -out newcertificate.csr

Sign the request of certificate with the private key of the CA

openssl x509 -req -days 1000 -in newcertificate.csr -signkey CA.key -out newcertificate.crt

How to make a self signed CA trusted

We need to configure myCA.pem as a Certification Authority in the computer where we want this certificate to be trusted.

In order to make myCA.pem a trusted certificate we have to copy this file into a specific openssl directory and then create a symbolic link to the same file which name has to be the hash of the entire certificate concatenated with “.0”. The location of this directory depends on the operating system which openssl is running on. On a linux machine we have to run these commands:

  1. copy myCA.pem into /etc/ssl/certs/:
    cp myCA.pem /etc/ssl/certs
  1. compute the hash of the certificate:
    openssl x509 -noout -hash -in myCA.pem

  1. create symbolic link to myCA.pem. The output of the previous command has to be concatenated with “.0”. (Assume that this output is d2d5febd.)
    ln -s /etc/ssl/certs/myCA.pem /etc/ssl/certs/d2d5febd.0

We can successfully verify myCA.pem with the command:

openssl verify myCA.pem

The MPS server is now able to sign a Certificate Signing Request. A CSR is an unsigned copy of an user's certificate submitted to a CA to be signed; with a CRS a CA will generate a valid trusted certificate.

Note that with the latest implementation of MPS you can use the trustedcerts folder instead of system folder.

"Certificate Signing Request" (CSR) creation and signing

In a standard PKI architecture a client who requires a signed certificate creates a public and private key pair, generates its CSR and submits it to a trusted CA.

In order to create a CSR we have to run these commands:

  1. Create a key pair user.key:
    openssl genrsa -out user.key 2048
  2. Create the request user.req:
    openssl req -new -key user.key -out user.req -subj '/CN=Marco Bonola/C=it/ST=roma/L=rm

With -subj option we specify a basic set of user attributes, i.e.: Common Name, Country, State (or province), City, email address.

It's possible to set X.509v3 extra attributes (see for a detailed documentation) with the option -extfile filename where filename is used to assign a given value to any arbitrary extension. The file must contain the keyword extension as in the following example:

extension = extend

[extend]  // below will follow the extension list
nsComment = "This is a test comment for the Netscape Comment (nsComment) standard extension"

One can also embed the extension value inside the openssl.cnf file:

-extfile openssl.cnf -extensions "ext_sec"

where ext_sec is a given section in openssl.cnf.

For example:

-extfile openssl.cnf -extensions v3_ca

If we want a non-standard extension to be included in the (signed) request we must register a new OID (Object IDentifier, see We can do this by first assigning a short name to the new oid, in the oid_section of the openssl.cnf file

oid_section = new_oids  # we are using an alternate section name, see

grant =       # "grant" is the short name for our non-standard extension, corresponding to our new oid

After this, we can assign the desired value in the proper [extension_section] via the DER encodig. Nevertheless, if the value to be assigned is a simple string, we can simply use the mini-ASN1 compiler (see


grant = critical,ASN1:UTF8String:"value = 1000"

Assume that the user.req CSR is submitted to the CA to be signed; the command to sign user.req on the CA machine is:

openssl x509 -req -in user.req -CA CA.pem -CAkey CA.key -CAserial serial -out user.pem -days 365

The -CA and -CAkey options respectively specify the CA's certificate and the CA's key.

With -CAserial option we specify the file which the CA take a number from in order to set serial number field in the certificate. As know the serial number of a set of issued certificate from the same CA has to be unique; for any new issued certificate the number in the serial file is stored in the serial number field and then increased.

The -days option is used to set the validity period of the issued certificate; in this example the validity is set to 1 year.

SPARTA details

To learn the procedures to obtain the certificates issued in the SPARTA framework read FrameworkCertificates and SpartaHandshakes

Revocation Management

To revoke a certificate:

openssl ca -revoke certificate.pem -config openssl.cnf

To create (or update) a crl:

openssl ca -gencrl -out crl.pem -config openssl.cnf

To verify if a certificate has been revoked:

openssl verify -CAfile crl.pem -crl_check cerficate.pem

(Openssl.conf has to be copied in the same folder we run theese commands from and modified. See openssl documentation for how to modify openssl.conf)

Sign a digest and verify the signature

We need a public/private key pair:

openssl genrsa -out mySIGNER.key 2048
openssl rsa -in mySIGNER.key -pubout > mySIGNER.pubkey


openssl dgst -sha1 -sign mySIGNER.key file.txt > digest_signature


openssl dgst -sha1 -verify mySIGNER.pubkey -signature digest_signature < file.txt
  • returns 0 if Verified OK
  • returns 1 if Verification Failure

try yourself with echo $?

Note that digest is not representable as ASCII so if you have to transfer a digest e.g. in a HTML Form you will have to base64 encode it!

Last modified 11 years ago Last modified on Feb 21, 2008, 9:49:42 AM