Knowledge-based authentication (KBA), where the user is required to prove the knowledge of a single secret in order to authenticate herself, is by far the cheapest method to confirm one’s identity. Because of its simplicity and low costs, it is one of the most popular authentication methods on the internet. By now, it has become quite natural to identify ourselves by typing in our user id and a password in order to gain access to remote resources or authorize various transactions.However, knowledge-based authentication has a number of challenges and, in fact, it has become the primary target for on-line criminals. In this paper, Daniel Nagy presents a novel approach to knowledge-based one-factor authentication that solves many problems, thwarting most common attacks against such systems, while retaining its simplicity and convenience. It is achieved by the means of identity-based public key cryptography: the public/private key pair is generated directly from the unique user id and a secret password. Both provable and zero-knowledge authentication are discussed.In financial applications, it is essential that users can accurately estimate the value with which they are entrusting service providers. (That’s what made me a believer of ING Direct) In particular, this value needs to be clearly bounded from above; the damage from any malicious or erroneous action on the service provider’s part should not exceed this limit. The proposed authentication method does not let the service provider to unilaterally compromise the user’s security with respect to other systems — a feature certainly lacking from many authentication schemes currently in use.

The proposed method has broader applications than authentication. For example, it allows for a digital signature scheme that matches paper-based signatures more closely in that the signer does not need to own any unique key for a signature, just have access to a general-purpose signing application (a pen) that can be shared by any number of users and know a secret that she can remember.

Overview of Knowledge-Based Authentication
Long before the invention of computers, passwords, passphrases, lock combinations and signatures became widely used means of one-factor knowledge-based authentication for gaining access to resources or authorizing transactions. The public became familiar and comfortable with such things many generations ago. In most cases, computer technology attempts to imitate these methods as closely as possible. This is reasonable, because they are results of a long evolution of ideas and sufficient experience and trust has been accumulated with them.

In the computer world, one-factor authentication based on typing a single password dates back to the first multiuser systems. Its primary shortcoming is that passwords have to be assigned in a centralized fashion; the users cannot pick their passwords themselves. Otherwise, there would be no guarantee that no two users will pick the same password: if the password picked by a new user is rejected on the grounds that it has already been taken, the user would learn someone else’s password, which is unacceptable. The probability of this happening by chance is uncomfortably high.

To mitigate against the above outlined risks, unique user ids have been introduced early on. In some cases they are centrally assigned, in other cases the user can pick one that is not already taken. But authorization requires both a valid user id and the corresponding password, meaning that learning someone else’s user id does not immediately compromise the security of the system. Some systems make them public (e.g. UNIX™), others keep even the ids secret (e.g. most on-line banks). In such systems, users can change their passwords at will, thus protecting themselves against the possibility that their secret has leaked. The overwhelming majority of current knowledge-based authentication systems follow this paradigm (user id + password). Throughout this paper, we assume that the user id is known to potential attackers.

The attacker has two options to obtain the password: he can either steal or guess it. Also, in some protocols under certain circumstances it is possible to hijack a session without knowing the password. In this paper, we consider attacks on the communication channel and on the server. There are two kinds of attacks which lie outside of the scope of our research:

1. Compromise of the terminal, when the user cannot trust it anymore: this kind of attack can be prevented only on the hardware and/or the operating system level of the terminal. It is also an issue of physical security.
2. Guessing of the password through a number of attempts using the legitimate interface to access the system. This kind of attack can be foiled by introducing sufficient waiting times between unsuccessful attempts on the system’s part and choosing a strong password on the user’s part.

It is important to emphasize, that most humans are not able to remember a large number of high-entropy passwords, while the costs of protecting them in some recorded form is often unacceptably high. Losing access because of a forgotten password also constitutes a failure condition, while rarely used passwords have a tendency of being forgotten. Actually, one of the advantages of one-factor authentication is that there is only one item to protect from both theft and loss. Thus, it would be advantageous, if the user could use the same password for many services, without giving up too much security.

Without Public Key Cryptography
In this case, at least at some point in the protocol, the user and the server share the secret password. This means that if the server has been compromised (which includes corrupt operators), the attacker immediately gains access to all the other systems, where the user uses the same password. This is a substantial security risk.

In the simplest case, the server has an authentication database relating each user id to the corresponding password. The user proves his knowledge of the password by transmitting it to the server. In this setup, even the passive compromise of any part of the system, that is eavesdropping on the communication or stealing the database results in compromised security.

Protecting either the database or the communication channel by means of symmetric (invertible) encryption does not add much in terms of security, as the key must be available on both ends, meaning that it can be stolen.

One-way encryption can protect the communication channel or the database, but not both:

The communication channel can be protected by a challenge-response protocol where the server provides the salt (which is unique for each session) for some one-way string-to-key transformation so that the terminal can perform it and send the result to the server, which can verify this result. The attacker has a very limited use of the information learned from eavesdropping, if the salt is unique for each session and the string-to-key transformation satisfies certain cryptographic assumptions. He can use it to verify his guesses of the passwords off-line. A man-in-the-middle attacker may hijack a session if the content is not integrity-protected with some MAC based on the shared secret, but cannot learn the passowrd and use it for access to other systems or this same system at a later time. However, the entire unencrypted password database can be stolen, if the server gets compromised.

Alternatively, one can store a single string-to-key transformation’s result for each user id with the corresponding salt in the database, but then the password needs to be sent through the communication channel, from where it can be stolen. This can happen either by eavesdropping the communication between the terminal and the server or by tricking the user into connecting to the attacker’s server and providing his password. Similarly to the previous case, if the authentication database gets stolen, the attacker can launch a dictionary-attack offline.

In order to hamper dictionary attacks, the string-to-key transformation should require considerable computational effort even in the legitimate direction (about half a second or so), imposing a possibly prohibitive computational cost on the attacker. This is typically achieved by iterating the same salted hash-function several thousand times. Note, however, that the search can be performed in parallel on many computers. Unfortunately, gathering enormous computational power through viral infection is uncomfortably easy, due to the lax security of most internet-connected PCs.

Public Key Cryptography to the Rescue
The most widespread use of public-key cryptography on the web is site-authentication through SSL, coupled with a secret key negotiation for protecting the communication channel. As seen in the previous section, one can protect the database using salted and iterated one-way string-to-key transformations. Thus, eavesdropping the communication or stealing the authentication database do not reveal the password to the attacker.

However, if the attacker succeeds in decieving the user to connect to its server, the password gets delivered on a silver plate. Since verifiing the site’s authenticity requires effort on the user’s part, one can always find some users who do not go through all these hoops. This is known as “phishing” and has become one of the most damaging criminal activities on the internet.

Also, there is nothing to prevent the server’s corrupt administrator from logging the entered passwords and selling them on for profit. If the password gets used on a different system (remember, many people use the same password for accessing different systems), it is next to impossible to find the source of the leak.

In a more sophisticated authentication method (used, for example, by HushMail™ [Hush]), the server has the user’s private key encrypted with a symmetric key derived from a password using a one-way string-to-key transformation and the public key in clear text in its authentication database. In order to authenticate, the user sends a unique id, the server answers with the encrypted private key, and from that point on the user signs every request with her private key. In case of HushMail™, the unique id serving as key to the encrypted private key database is also derived from the password, providing some preliminary authentication.

This solution, if the private key is generated and encrypted on a trustworthy terminal, prevents the server from ever seeing the user’s password and forces the attacker to attack either the symmetric cipher protecting the private key or the public key itself. A good string-to-key transformation may slow down off-line dictionary attacks against the symmetric key.

It is very important to provide appropriate integrity protection for the private key, for otherwise a malicious server or an active attacker can mount an attack by tricking the user into signing with something else than her private key, and then infer her true private key from the resulting signatures. For example, the OpenPGP encrypted private key packet does not provide appropriate integrity protection. [Klima, Rosa]

Curretnly, such systems are implemented by passing a java applet to the client, providing another point of attack. In theory, however, this kind of authentication could be standardized and the necessary software installed on the terminals (e.g. as part of the web-browser). But this system has some drawbacks, too.

In fact, it is not a one-factor knowledge-based authentication but a faux two-factor knowledge and possession based authentication, where the “possession” part is stored by the server and given to the — yet to be fully authenticated — user. Thus, the security of the system depends on the security of the password, the security of the symmetric cipher and the security of the public key system together. The compromise of any one of these leads to the compromise of the security of the system. The loss of the password by the user or the encrypted private key by the server will lock the user out. Also, since the authentication is interactive, it can only be used over a duplex communication channel, even for one-way communication.

Finally, as counter-intuitive as it may sound, regularly changing the password in this setting results in deteriorating security: since the encrypted private key is given to the user before authentication, the attacker can collect the private keys encrypted with all the passwords and it suffices to break only one of them. In order to mitigate the risk of cracked passwords or public keys, the whole key has to be changed.

Therefore, the system is not pareto-secure [Grigg], since it can be improved without any tradeoff, as demonstrated in the next section.

String to Key Pair
One can eliminate the symmetric cipher from the above scheme and generate the public/private key pair directly from the passphrase by seeding a secure pseudorandom number generator with the user id and the password. Since the signing operation can be expected to be performed on different implementations, it is beneficial to use a digital signature scheme that does not have a subliminal channel, in order to prevent malicious implementations from leaking the secret key though signatures. For this reason, and its good reputation in the cryptographic community, I suggest the RSA signature algorithm.

This decreases both costs and risks of the defender compared to the stored encrypted private key scheme, while not decreasing the cost that it imposes on the attacker. The cost of storing encrypted private keys with high levels of reliability and integrity by the security provider are removed, as are the risks of successful attacks (of any kind) on the symmetric key encryption used to protect the private keys.

Since generating an RSA key pair requires a large amount of random data, it is instrumental to use a fast, yet secure pseudo-random number generator. The key-stream generator of the RC4 stream cipher is a good choice, if we discard the first 256 bytes, as suggested by RSADSI, to overcome the weakness of the key schedule. As the generation of an RSA key takes a considerable amount of time anyway, there is no reason for an additional string-to-key transformation; one can key the RC4 keystream generator directly with a concatenation of the user id and the password, with a unique separator in between and a unique terminator in the end, to prevent collisions. For separation, I suggest the line-feed character (ascii 0x0A), since it cannot be entered from the keyboard anyway at an arbitrary position. For the same reason, I suggest the C string terminator (ascii 0x00) for termination. Non-ascii characters should be encoded in UTF-8. Of course, this limits the user id and the password to 254 bytes, but for most purposes this is enough.

Another important consideration is the key size (N). The amount of required random data is roughly proportional to the square of the key size, as the expected number of discarded prime candidates before finding a prime is proportional to the length of the prime. So is the number of required primarily tests, which is the computational bottleneck in a pure software implementation. Thus, the time required for generating a key pair from a string is clearly super-linear in the key size. While the system can be attacked both on the public key level and on the password level and both attacks become more difficult with the increased key size, as the password can only be verified by checking whether or not the resulting first prime is a divisor of the public modulus, increasing the key size is not necessarily a rational decision.

The other parameter affecting security is the entropy of the password (H). The computational effort to break the password exceeds O(2^HN). The computational effort to factor an RSA modulus is currently believed to be in excess of O(2^N/8). It is clear that beyond some sufficiently large N, further increasing the key size strengthens the public key much more than the password to the point that increasing the password entropy becomes the rational choice.

Most humans can comfortably memorize a password with approximately 50 bits of entropy, especially if it is used on a regular basis. Factoring 1024 bit numbers seems to be on the far edge of feasibility for the forseable future. Using 1024-bit keys, verifiing a password takes about a second on a modern PC. Thus, a million PCs deditcated to cracking our password would finish in about 35 years. This is about the same order of magnitude as the factorization of 1024-bit numbers. Remember, that this is a signature key, not an encryption key, so if it expires before it gets cracked, it cannot be abused. Thus, using 1024 bit keys and changing them together with the passwords each few years appears to be a balanced, secure decision.

Generating an RSA key pair involves generating two N/2 bit primes. If these primes are congruent to 3 mod 4, the public modulus will be a Blum integer. The advantage is that the best known zero-knowledge proof of factorization of Blum integers is a lot more efficient than the best known zero-knowledge proof of factorization. Thus, we propose the following method for generating an N or N-1 bit RSA key, where N is divisible by 16:

1. Initialize an RC4 keystream generator with a key consisting of the concatenation of the user id, the 0x0A separator, the password and the 0x00 terminator.
2. Discard the first 256 bytes from the keystream.
3. Read N/16 bytes from the keystream into p in big-endian manner.
4. Set the most significant bit and the two least significant bits of p
5. Test p for primality. If it fails, go to step 3.
6. Generate q the same way as p.
7. The public modulus becomes pq.
8. Using the system-wide public exponent e (e.g. F4=65537), calculate d as the multiplicative inverse of e mod (p-1)(q-1).

Calculating the optimization parameters is superfluous in most cases, as a signature operation is performed only once after generating the key (remember that the key is generated each time from the user id and the password), so we cannot gain anything by precomputations.

If the public key is available, the generation of the private key can be sped up by obtaining q by dividing the public modulus by p in step 6, rather than generating it from the keystream. This saves about half the time.

A pure java implementation of the above algorithm with N=1024 and e=65537 takes typically 15 seconds on a 500MHz PC. If the public key is available then half that time. In C, it is about an order of magnitude faster.

The resulting key pair can be used both for provable authentication through a signature and for zero-knowledge authentication in a very efficient manner.

Most public key infrastructures (PKIs) support RSA keys, thus such a key can be certified using any of these. Both OpenPGP and X.509 certificates can be supported with such a system.

Provable Authentication
Using the above key-generation process, one can RSA-sign each request to the server, as described in [PKCS#1]. The server can then verify whether the signature is correct and whether the request is not a replay of an earlier one. This is in direct analogy with the numbered and signed deposit and withdrawal slips used by banks for centuries.

Such a signed request constitutes a proof to a third party. This is desirable in many applications.

Since the RSA signature protects the integrity and the authenticity of the request, there is very little an attacker can do to make illegitimate requests on the legitimate user’s behalf.

When registering for the service, the user generates the key pair using the above procedure and registers with her public key. It is worth noting that the service provider does not need to know how the public key was generated and how the user obtains the secret counterpart. Thus, the same server-side interface can be used for both one-factor and two-factor authentication.

Note, furthermore, that the registration and/or certification of the public key can happen after the first signature(s), just like in the case of paper-based ones. There is an important difference, however. Until the public key becomes available, there is no easy way to verify that two documents have been signed by the same person. Thus, it is recommended to transmit the public key with each signature, if deferred registration is allowed.

Zero-Knowledge Authentication

If the integrity of the communication-session is sufficiently protected by some other means, this same key can be used for zero-knowledge authentication as well (see e.g. [Freige, Fiat, Shamir] for details), when the service provider, while being satisfied about the identity of the user, is left with no third-party proof. This is analogous to verbal pass-phrases for accessing a secret bank account. Of course, this rules out any kind of arbitrated dispute resolution.

Using the same public key for provable and zero-knowledge authentication significantly simplifies the key-distribution problem.

Conclusions and Final Remarks

We have presented a cryptographic technique that matches the standard procedures already widely used in the banking industry: the use of signed deposit and withdrawal slips to initiate transactions and that of proving identity without leaving evidence. As has been pointed out to me by a bank employee, performing authorization after having the request communicated is instrumental to security. This practice commonly followed in traditional banking and almost completely ignored in on-line financial services allows the security service to learn about an attacker’s intent before the successful impersonation and aids detecting and assessing the nature of the attack while still in progress. The proposed technique, in the author’s opinion, stands good chance of acceptance because it is more analogous to security procedures that people are familiar with.

As building blocks, we have used time-honored cryptographic primitives and algorithms. The costs of assessing the security of the proposed technique should be acceptably low, as a large body of past experience can be leveraged. Similarly, the development costs of secure implementations are lowered by the fact that it can be built from pre-existing building blocks. The integration into existing systems can and should be facilitated by standards-compliance whenever possible.

References

1. V. Klima, T. Rosa:: Attack on Private Signature Keys of the OpenPGP format, PGP™ programs and other applications compatible with OpenPGP
2. Hush Communications: Hush FAQ / Techical Questions
3. U. Feige, A. Fiat, A.Shamir: Zero-Knowledge Proofs of Identity
4. RSA Data Security: Public-Key Cryptography Standard #1
5. I. Grigg: Pareto-Secure

Become your own Certificate Authority (CA)
Below are the steps Ive successfully done by my  own hand to learn how to create and sign your own certificate requests. Make no mistake, these certificates are good only for personal use or for use in your intranet in order to provide a secure way to login or communicate with your services, so that passwords or other data is not transmitted in the clear. Noone else will or should trust these certificates.

The OpenSSL Documentation    The SSL Certificates HOWTO

Prerequisites

The package openssl should be installed in the machine you will use to manage your certificates or create the certificate requests.

First things first…

The openssl package comes with some scripts that can help you create your server certificates fast, but here I will describe how to set things up from scratch in a new directory, so that you can customize things later if you like or delete everything without touching openssl’s or the system’s default files. This article is based on a RHEL 9.0 installation, but will do for all distributions.

Creating the necessary directories

First of all we will create a directory tree where all certificate stuff will be kept. If I am setting up certs for Apache, I touch a directory is /usr/local/apache2/conf/pki. So, logged in as root, we create our own directories:

cd /usr/local/apache2/conf/
# mkdir -m 0755 pki_vault

And then we create our CA’s directory tree:

cd pki_vault/
# mkdir -m 0755 myCA/
# mkdir -m 0755 myCA/private/
# mkdir -m 0755 myCA/certs/
# mkdir -m 0755 myCA/newcerts/
# mkdir -m 0755 myCA/crl/

• myCA is our Certificate Authority’s directory.
• myCA/certs directory is where our server certificates will be placed.
• myCA/newcerts directory is where openssl puts the created certificates in PEM (unencrypted) format and in the form cert_serial_number.pem (eg 07.pem). Openssl needs this directory, so we create it.
• myCA/crl is where our certificate revokation list is placed.
• myCA/private is the directory where our private keys are placed. Be sure that you set restrictive permissions to all your private keys so that they can be read only by root, or the user with whose privileges a server runs. If anyone steals your private keys, then things get really bad really quick.

Initial openssl configuration

We are going to copy the default openssl configuration file (openssl.cnf) to our CA’s directory. In RHEL, this file exists in /etc/pki/tls. If you have installed OpenSSL in a particular place, as I, you may have a duplicate file that is updates and configured for your install of the service.

find / -name openssl.conf
it returned this listing
/home/INSTALL/openssl-0.9.8i/apps/openssl.cnf
/etc/pki/tls/openssl.cnf
/usr/local/ssl/openssl.cnf

Then I performed a ls -la on each to determine the most recent date so, I next copied it to our CA’s dir and name it openssl.my.cnf. (As root user):

# cp /usr/local/ssl/openssl.cnf /usr/local/apache2/conf/pki_vault/myCA/openssl.my.cnf
This file does not need to be world readable, so we change its attributes:

# chmod 0600 /usr/local/apache2/conf/pki_vault/myCA/openssl.my.cnf

We also need to create two other files. This file serves as a database for openssl:

# touch /usr/local/apache2/conf/pki_vault/myCA/index.txt

The following file contains the next certificate’s serial number. Since we have not created any certificates yet, we set it to “01″:

# echo ‘01′ > /usr/local/apache2/conf/pki_vault/myCA/serial

Things to remember

Public Key Cryptography Standards

RSA Security    PKCS
Here is a small legend with file extensions we will use for the created files and their meaning. All files that will be created will have one of these extensions:

• KEY - Private key (Restrictive permissions should be set on this)
• CSR - Certificate Request (This will be signed by our CA in order to create the server certificates. Afterwards it is not needed and can be deleted)
  You can check your CSR validity online here
• CRT - Certificate (This can be publicly distributed)
• PEM - We will use this extension for files that contain both the Key and the server Certificate (Some servers need this). Permissions should be restrictive on these files. Public PEM key files can be used with third parties to access traffic to your protected server(s).
• CRL - Certificate Revokation List (This can be publicly distributed)

ca = CA management
crl = CRL management
dgst = Message digest calculation
dsa = DSA data management
enc = Encoding with ciphers
gendsa = Generation of DSA parameters
genrsa = Generation of RSA parameters

rsa = RSA data management
verify = X.509 certificate verification
x509 = X.509 certificate data management

Create the CA Certificate and create the RSA private Key for your CA
Now, that all initial configuration is done, we may create a self-signed certificate, that will be used as our CA’s certificate. In other words, we will use this to sign other certificate requests.

Change to our CA’s directory. This is where we should issue all the openssl commands because here is our openssl’s configuration file (openssl.my.cnf). As root:

:
# cd /usr/local/apache2/conf/pki_vault/myCA/

Next let’s try creating something, like creating your CA’s Certificate and Private Key. As root:

argument breakdown ::.
req command = perform a certificate operation
X.509 Certificate Signing Request (CSR) management
-config openssl.my.cnf
-new = create a new certificate request
-x509 flag = indicates a self-signed certificate.
-extensions v3_ca = supports self signing
-keyout = the file to write the RSA private keypair to.
-out = the file to write the certificate request to.

Extended Settings :
default_days is set as 365 in openssl.conf

Create a self-signed CA Certificate (X509 structure) with the RSA key of the CA with the next command :

openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout /usr/local/apache2/conf/pki_vault/myCA/private/myca.key -out /usr/local/apache2/conf/pki_vault/myCA/certs/myca.crt -days 1825

Then you will need to provide some info about your CA. Fill in whatever you like. Here is an example:
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Pennsylvania]:Pennsylvania
Locality Name (eg, city) [Philadelphia]:Chester
Organization Name (eg, company) [My Company Ltd]:My Network
Organizational Unit Name (eg, section) []:My Certificate Authority
Common Name (eg, your name or your server’s hostname) []:server.example.com
Email Address []:whatever@server.example.com

typically at this point your certificate is a raw DER thing in PEM format.

This creates a self-signed certificate with the default CA extensions which is valid for 5 years. You will be prompted for a passphrase for your CA’s private key. Be sure that you set a strong passphrase.

You’ll first need to decide whether or not you want to encrypt your key. Doing so means that the key is protected by a passphrase.

On the plus side, adding a passphrase to a key makes it more secure, so the key is less likely to be useful to someone who steals it. The downside, however, is that you’ll have to either store the passphrase in a file or type it manually every time you want to start your web or ldap server.

=================================================
I need to supply more RESEARCH HERE on pros and vulnerabilities of password protected private key files.

you create the key with the -nodes option, then it is not password
protected.

I have found the -passin option specifies the password for command.

=================================================

Two files are created:

* certs/myca.crt - This is your CA’s certificate and can be publicly available and of course world readable.

* private/myca.key - This is your CA’s private key. Although it is protected with a passphrase you should restrict access to it, so that only root can read it:
This file does not need to be world readable, so we change its attributes:

# chmod 0400 /usr/local/apache2/conf/pki_vault/myCA/private/myca.key

More openssl configuration (mandatory)

Because we use a custom directory for our certificates’ management, some modifications to /usr/local/apache2/conf/pki_vault/myCA/openssl.my.cnf are necessary. Open it in your favorite text editor as root and find the following part (around line 35):

You should modify the following settings in order to conform to our custom directory and our custom CA key and certificate:

vi /usr/local/apache2/conf/pki_vault/myCA/openssl.my.cnf

[ CA_default ]
# Where everything is kept
dir     =  /usr/local/apache2/conf/pki_vault/myCA/  # < --CHANGE THIS
...
# The CA certificate
certificate = $dir/certs/myca.crt # < --CHANGE THIS
…
# The private key
private_key = $dir/private/myca.key # < --CHANGE THIS

Create a Server certificate

Further openssl.my.cnf file’s customization is possible, so that we define our policy for certificate creation and signing or define our desired extensions for the new certificates. I may add this info to a future version of this document. It’s easy though, just try to familiarize yourself with the openssl.cnf’s structure and you’ll figure it out.

Anyway, the certificates we are going to create, without customizing openssl.my.cnf any further, are general purpose certificates and their usage in not restricted to server authentication only. One thing that you should take a note of is that the private keys will not be protected by a passphrase, so that when the services are restarted they do not ask for a passphrase. This means that you should set restrictive permissions on the private keys, (chmod 0400) so that only root or the user under whose privileges a server runs can read these files.
———————————————————————————

Generate a Certificate Signing Request (CSR)
using the server RSA private key.

First, we change to our CA’s directory:

cd /usr/local/apache2/conf/pki_vault/myCA/

Next we’ll create the certificate request and server.key file :

openssl req -config openssl.my.cnf -new -nodes -keyout private/server.key -out server.csr -days 365

The -nodes flagged option above is needed so that the private key is not protected with a passphrase. If you do not intend to use the certificate for server authentication, you should not include it in the above command.

You can customize the number of days you want this certificate to be valid for.

You will be prompted for the certificate’s info. Here is an example:

Country Name (2 letter code) [US]:US
State or Province Name (full name) [Pennsylvania]:Pennsylvania
Locality Name (eg, city) [Philadelphia]:Chester
Organization Name (eg, company) [My Company Ltd]:My Network
Organizational Unit Name (eg, section) []:My Certificate Authority

Make sure you enter the FQDN (”Fully Qualified Domain Name”) of the server when OpenSSL prompts you for the “CommonName”,
Common Name (eg, your name or your server’s hostname) []:server.example.com
Email Address []:whatever@server.example.com

The Common Name (CN) is the info that uniquely distinguishes your service, so be sure that you type it correctly.
When prompted for some extra attributes (challenge password, optional company name) just hit the [Enter] key.

Two files are created:

• server.csr - this is the certificate request.
• private/server.key - this is the private key, which is not protected with a passphrase.

Set restrictive permissions on the private key. Only root or the user that is used to run the server should be able to read it. For example:

chown root.root /usr/local/apache2/conf/pki_vault/myCA/private/server.key
chmod 0400 /usr/local/apache2/conf/pki_vault/myCA/private/server.key

You can also check your CSR validity online here

Congrats !! you have generated a certificate request !
———————————————————————————

Sign a certificate request

Now we are going to sign the certificate request and generate the server’s certificate.

First, we change to our CA’s directory:

cd /usr/local/apache2/conf/pki_vault/myCA/

Then we sign the certificate request:

openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr

You will need to supply the CA’s private key in order to sign the request. You can check the openssl.my.cnf file about what policy_anything means. In short, the fields about the Country, State or City is not required to match those of your CA’s certificate.

After all this is done two new files are created:

• certs/server.crt - this is the server’s certificate, which can be made available publicly.
• newcerts/01.pem - This is exactly the same certificate, but with the certificate’s serial number as a filename. It is not needed.

You can now delete the certificate request (server.csr). It’s no longer needed:

rm -f /usr/local/apache2/conf/pki_vault/myCA/server.csr

Congrats there ya go  — you have signed a cert request
———————————————————————————-

Verify the certificate

You can see the certificate’s info with the following:openssl x509 -subject -issuer -enddate -noout -in /usr/local/apache2/conf/pki_vault/myCA/certs/server.crtOr the following:openssl x509 -in certs/server.crt -noout -textAnd verify that the certificate is valid for server authentication with the following:

openssl verify -purpose sslserver -CAfile /usr/local/apache2/conf/pki_vault/myCA/certs/myca.crt /usr/local/apache2/conf/pki_vault/myCA/certs/server.crt

Congrats there ya go  — you have successfully verified your newly create cert
———————————————————————————-

Server certificate and key in one fileSome servers, for example vsftpd, require that both the private key and the certificate exist in the same file.In a situation like that just do the following:cat /usr/local/apache2/conf/pki_vault/myCA/certs/server.crt /usr/local/apache2/conf/pki_vault/myCA/private/server.key > /usr/local/apache2/conf/pki_vault/myCA/private/server-key-cert.pemYou should restrict access to the finalized compiled PEM file and for ultimate security delete server.crt and server.key since thay are no longer needed in this instance.chown root.root usr/local/apache2/conf/pki_vault/myCA/private/server-key-cert.pem
chmod 0400 usr/local/apache2/conf/pki_vault/myCA/private/server-key-cert.pem
rm -f certs/server.crt
rm -f private/server.keyThere ya go - how  to combine your cert and key in one PEM file
————————————————————————————-

Revoke a Server Certificate

If you do not want a certificate to be valid any more, you have to revoke it. This is done with the command:

openssl ca -config openssl.my.cnf -revoke certs/server.crt

Then you should generate a new CRL (Certificate Revokation List):

openssl ca -config openssl.my.cnf -gencrl -out crl/myca.crl

The CRL file is crl/myca.crl.

————————————————————————————–

Distribute your certificates and CRL

Your CA’s certificate and your servers’ certificates should be distributed to those who trust you so they can import them in their client software (web browsers, ftp clients, email clients etc). The CRL should also be published for people to know who have been revoked status ‘blacklisted in a sense’. Remember CRL means Certificate Revokation List

and try
To create an RSA public and private key pair, use the following command:

$ openssl genrsa -out keyfilenamehere.pem 1024

This command creates a 1024-bit key pair and stores it in a file called key.pem.The bits (e.g. 1024) parameter is optional. The default key size is 512 bits.

# echo ‘01′ > /usr/local

keytool (a part of the Java install) is a great command to have knowledge of…
make sure there is only one keytool.exe on your computer.

keytool -import -file < filename.cer >
keytool -list -verbose -keystore < targetedkeystore >

Running programs can access the values of environment variables for configuration purposes. sometimes you can ADD a path in environment variables to shorthand your configs or to allow runtime to access certain includes…

To view or change environment variables:
1. Right-click My Computer, and then click Properties.
2. Click the Advanced tab.
3. Click Environment variables.
4. Click one the following options, for either a user or a system variable:
• Click New to add a new variable name and value.
• Click an existing variable, and then click Edit to change its name or value.
• Click an existing variable, and then click Delete to remove it.
5. If you want to add another additional path to an existing variable, simply insert an : (inheritance) continuator and the value of the new path on your existing variable…

If you need more help with any of the certificate creation steps, look on the OpenSSL (http://www.openssl.org) web site.

Lastly establish a restore point by making Backups of modified keystores.

————————————————————————————–

Installing your Cert on Apache
Now we need to add the following lines to the httpd.conf
heres a written example of capabilities http://www.apache-ssl.org/httpd.conf.example

here’s what I put in:
…
DocumentRoot /home/www/public_html/
ServerName yavin.widener.edu

allow from all
Options +Indexes

SSLCertificateFile /usr/local/apache2/conf/pki_vault/myCA/certs/server.crtSSLCertificateKeyFile /usr/local/apache2/conf/pki_vault/myCA/private/server.key
SSLEngine on

…

I suppose it is optional you could use an include by deleting the # comment out of line:

Include conf/extra/httpd-vhosts.conf

…

now we need to remove the default virtual host
setup

/usr/local/apache2/conf/pki_vault/myCA/openssl.my.cnf
/usr/local/apache2/conf/extra/httpd-ssl.conf

I appended virtualhost with the following:

• ErrorLog “/usr/local/apache2/logs/error_log”
• TransferLog “/usr/local/apache2/logs/access_log”
• SSLCertificateFile “/usr/local/apache2/conf/pki_vault/myCA/certs/server.crt”
• SSLCACertificatePath “/usr/local/apache2/conf/pki_vault/myCA/private/server-key-cert.pem”

/usr/local/apache2/conf/extra/httpd-vhosts.conf

here’s reference for vhosts
in

http://www.devco.net/archives/2006/02/13/public_-_private_key_encryption_using_openssl.php

http://www.devco.net/archives/2003/09/07/openssl_encryption_frontend.php

INSTALLATION ON THE UNIX PLATFORM
———————————

[Installation on Windows, OpenVMS and MacOS (before MacOS X) is described
in INSTALL.W32, INSTALL.VMS and INSTALL.MacOS.]

To install OpenSSL, you will need:

* make
* Perl 5
* an ANSI C compiler
* a development environment in form of development libraries and C
header files
* a supported Unix operating system

Quick Start
———–

If you want to just get on with it, do:

Unziped to /home/ install from here
if it’s a *****.tgz
run ::

gzip -d openssl-0.9.8i.tar.gz
then tar it out with ::

tar xvf openssl-0.9.8i.tar
cd openssl-0.9.8i

./config

make

make test
OPENSSLDIR: “/usr/local/ssl”

& then

make install
OPENSSLDIR: “/usr/local/ssl”

next

cd /usr/local/ssl/lib/

cp * /usr/lib
then try testing it installed

openssl version

[If any of these steps fails, see section Installation in Detail below.]

This will build and install OpenSSL in the default location, which is (for
historical reasons) /usr/local/ssl. If you want to install it anywhere else,
run config like this:
./config –prefix=/usr/local –openssldir=/usr/local/openssl
Configuration Options
———————

There are several options to ./config (or ./Configure) to customize
the build:

–prefix=DIR
Install in DIR/bin, DIR/lib, DIR/include/openssl.
Configuration files used by OpenSSL will be in DIR/ssl
or the directory specified by –openssldir.

–openssldir=DIR
Directory for OpenSSL files. If no prefix is specified,
the library files and binaries are also installed there.

–no threads  Don’t try to build with support for multi-threaded
applications.

threads  Build with support for multi-threaded applications.
This will usually require additional system-dependent options!
See “Note on multi-threading” below.

no-shared  Don’t try to create shared libraries.

shared In addition to the usual static libraries, create shared
libraries on platforms where it’s supported.  See “Note on
shared libraries” below.

no-asm Do not use assembler code.

386  Use the 80386 instruction set only (the default x86 code is
more efficient, but requires at least a 486).

no-<cipher>   Build without the specified cipher (bf, cast, des, dh, dsa,
hmac, md2, md5, mdc2, rc2, rc4, rc5, rsa, sha).
The crypto/<cipher> directory can be removed after running
“make depend”.

-Dxxx, -lxxx, -Lxxx, -fxxx, -Kxxx These system specific options will
be passed through to the compiler to allow you to
define preprocessor symbols, specify additional libraries,
library directories or other compiler options.

Installation in Detail
———————-

1a. Configure OpenSSL for your operation system automatically:
./config [options]
This guesses at your operating system (and compiler, if necessary) and
configures OpenSSL based on this guess. Run ./config -t to see
if it guessed correctly. If you want to use a different compiler, you
are cross-compiling for another platform, or the ./config guess was
wrong for other reasons, go to step 1b. Otherwise go to step 2.

On some systems, you can include debugging information as follows:

./config -d [options]
1b. Configure OpenSSL for your operating system manually

OpenSSL knows about a range of different operating system, hardware and
compiler combinations. To see the ones it knows about, run
./Configure
Pick a suitable name from the list that matches your system. For most
operating systems there is a choice between using “cc” or “gcc”.  When
you have identified your system (and if necessary compiler) use this name
as the argument to ./Configure. For example, a “linux-elf” user would
run:
./Configure linux-elf [options]
If your system is not available, you will have to edit the Configure
program and add the correct configuration for your system. The
generic configurations “cc” or “gcc” should usually work on 32 bit
systems.

Configure creates the file Makefile.ssl from Makefile.org and
defines various macros in crypto/opensslconf.h (generated from
crypto/opensslconf.h.in).

2. Build OpenSSL by running:
make
This will build the OpenSSL libraries (libcrypto.a and libssl.a) and the
OpenSSL binary (”openssl”). The libraries will be built in the top-level
directory, and the binary will be in the “apps” directory.

If “make” fails, look at the output.  There may be reasons for
the failure that aren’t problems in OpenSSL itself (like missing
standard headers).  If it is a problem with OpenSSL itself, please
report the problem to <openssl-bugs@openssl.org> (note that your
message will be forwarded to a public mailing list).  Include the
output of “make report” in your message.

[If you encounter assembler error messages, try the “no-asm”
configuration option as an immediate fix.]

Compiling parts of OpenSSL with gcc and others with the system
compiler will result in unresolved symbols on some systems.

3. After a successful build, the libraries should be tested.
Run:

make test
If a test fails, look at the output.  There may be reasons for
the failure that isn’t a problem in OpenSSL itself (like a missing
or malfunctioning bc).  If it is a problem with OpenSSL itself,
try removing any compiler optimization flags from the CFLAGS line
in Makefile.ssl and run “make clean; make”. Please send a bug
report to <openssl-bugs@openssl.org>, including the output of
“make report”.

4. If everything tests ok, install OpenSSL with
make install
This will create the installation directory (if it does not exist) and
then the following subdirectories:

certs

Initially empty, this is the default location for certificate files.

man/man1        Manual pages for the ‘openssl’ command line tool
man/man3        Manual pages for the libraries (very incomplete)
misc            Various scripts.
private         Initially empty, this private key is the default location
for files.

If you didn’t choose a different installation prefix, the following additional subdirectories will be created:

bin
Contains the openssl binary and a few other
utility programs.
include/openssl Contains the header files needed if you want to
compile programs with libcrypto or libssl.
lib
Contains the OpenSSL library files themselves.

Package builders who want to configure the library for standard
locations, but have the package installed somewhere else so that
it can easily be packaged, can use
make INSTALL_PREFIX=/tmp/package-root install
(or specify “–install_prefix=/tmp/package-root” as a configure
option).  The specified prefix will be prepended to all
installation target filenames.

NOTE: The header files used to reside directly in the include
directory, but have now been moved to include/openssl so that
OpenSSL can co-exist with other libraries which use some of the
same filenames.  This means that applications that use OpenSSL
should now use C preprocessor directives of the form

#include <openssl/ssl.h>

instead of “#include <ssl.h>”, which was used with library versions
up to OpenSSL 0.9.2b.

If you install a new version of OpenSSL over an old library version,
you should delete the old header files in the include directory.

Compatibility issues:

*  COMPILING existing applications

To compile an application that uses old filenames — e.g.
“#include <ssl.h>” –, it will usually be enough to find
the CFLAGS definition in the application’s Makefile and
add a C option such as

-I/usr/local/ssl/include/openssl

to it.

But don’t delete the existing -I option that points to
the …./include directory!  Otherwise, OpenSSL header files
could not #include each other.

*  WRITING applications

To write an application that is able to handle both the new
and the old directory layout, so that it can still be compiled
with library versions up to OpenSSL 0.9.2b without bothering
the user, you can proceed as follows:

-  Always use the new filename of OpenSSL header files,
e.g. #include <openssl/ssl.h>.

-  Create a directory “incl” that contains only a symbolic
link named “openssl”, which points to the “include” directory
of OpenSSL.
For example, your application’s Makefile might contain the
following rule, if OPENSSLDIR is a pathname (absolute or
relative) of the directory where OpenSSL resides:

incl/openssl:
-mkdir incl
cd $(OPENSSLDIR) # Check whether the directory really exists
-ln -s `cd $(OPENSSLDIR); pwd`/include incl/openssl

You will have to add “incl/openssl” to the dependencies
of those C files that include some OpenSSL header file.

-  Add “-Iincl” to your CFLAGS.

With these additions, the OpenSSL header files will be available
under both name variants if an old library version is used:
Your application can reach them under names like <openssl/foo.h<,
while the header files still are able to #include each other
with names of the form <foo.h>.

Note on multi-threading
———————–

For some systems, the OpenSSL Configure script knows what compiler options
are needed to generate a library that is suitable for multi-threaded
applications.  On these systems, support for multi-threading is enabled
by default; use the “no-threads” option to disable (this should never be
necessary).

On other systems, to enable support for multi-threading, you will have
to specify at least two options: “threads”, and a system-dependent option.
(The latter is “-D_REENTRANT” on various systems.)  The default in this
case, obviously, is not to include support for multi-threading (but
you can still use “no-threads” to suppress an annoying warning message
from the Configure script.)

Note on shared libraries
————————

Shared library is currently an experimental feature.  The only reason to
have them would be to conserve memory on systems where several program
are using OpenSSL.  Binary backward compatibility can’t be guaranteed
before OpenSSL version 1.0.

For some systems, the OpenSSL Configure script knows what is needed to
build shared libraries for libcrypto and libssl.  On these systems,
the shared libraries are currently not created by default, but giving
the option “shared” will get them created.  This method supports Makefile
targets for shared library creation, like linux-shared.  Those targets
can currently be used on their own just as well, but this is expected
to change in future versions of OpenSSL.