From Fedora Project Wiki
(New page: (I have not contributed for a while and after typing this up, I realized I do not remember styles and tags. I will come back to this in couple of days with proper style.) Commercial SSL i...)
 
No edit summary
Line 4: Line 4:


Many guides in FOSS community suggest generation of self-signed certificates. Here any person (with openssl implementation) can act simultaneously CA and a client. This brings two deficiencies:  
Many guides in FOSS community suggest generation of self-signed certificates. Here any person (with openssl implementation) can act simultaneously CA and a client. This brings two deficiencies:  
1. There is no key in the system to recognize the certificate;
# There is no key in the system to recognize the certificate;
2. The certificate is self-signed, someone is certifying self
# The certificate is self-signed, someone is certifying self


We recommend eliminating at least Nr. 2 problem by switching two two tier hierarchy. You wil have to:
We recommend eliminating at least Nr. 2 problem by switching two two tier hierarchy. You wil have to:
1. Generate CA self signed certificate and key;
# Generate CA self signed certificate and key (this will ask for password)
#generates selfsigned CA certificate and key, will ask for password
#*openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config ./openssl.cnf
openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config ./openssl.cnf
# Generate clients key and a request to CA to sign the certificate (-nodes is for no password)
2. Generate clients key and a request to CA to sign the certificate
#*openssl req -nodes -newkey rsa:1024 -keyout key.pem -out req.pem -config ./openssl.cnf
 
# CA signs client request, and
#generates cert request and key, -nodes is for no password
#*openssl ca -in req.pem -out newcert.pem -config ./openssl.cnf
openssl req -nodes -newkey rsa:1024 -keyout key.pem -out req.pem -config ./openssl.cnf
#*Warning: Be careful to correctly edit the openssl.cnf file and move cakey.pem key as needed by config.
3. CA signs client request, and
# also issues certificate revocation list
#signes the request with authority key
#*openssl ca -gencrl -out crl.pem -config ./openssl.cnf
openssl ca -in req.pem -out newcert.pem -config ./openssl.cnf
Warning: Be careful to correctly edit the openssl.cnf file and move cakey.pem key as needed by config.
4. also issues certificate revocation list
#generate crl file
openssl ca -gencrl -out crl.pem -config ./openssl.cnf

Revision as of 07:25, 8 November 2008

(I have not contributed for a while and after typing this up, I realized I do not remember styles and tags. I will come back to this in couple of days with proper style.)

Commercial SSL is typically hierarchical. Normally there is certificate authority (CA) and a client. Public key of major CA's are provided together with OS, so client certificates signed by them are recognized out of box.

Many guides in FOSS community suggest generation of self-signed certificates. Here any person (with openssl implementation) can act simultaneously CA and a client. This brings two deficiencies:

  1. There is no key in the system to recognize the certificate;
  2. The certificate is self-signed, someone is certifying self

We recommend eliminating at least Nr. 2 problem by switching two two tier hierarchy. You wil have to:

  1. Generate CA self signed certificate and key (this will ask for password)
    • openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config ./openssl.cnf
  2. Generate clients key and a request to CA to sign the certificate (-nodes is for no password)
    • openssl req -nodes -newkey rsa:1024 -keyout key.pem -out req.pem -config ./openssl.cnf
  3. CA signs client request, and
    • openssl ca -in req.pem -out newcert.pem -config ./openssl.cnf
    • Warning: Be careful to correctly edit the openssl.cnf file and move cakey.pem key as needed by config.
  4. also issues certificate revocation list
    • openssl ca -gencrl -out crl.pem -config ./openssl.cnf