How can an SSL client verify a server certificate?
I am creating an application and I am planning to use OpenSSL to provide data transfer.
I am planning that the client only validates the server certificate. I am confused as to how I should secure the server certificate. I would like to encrypt the server certificate containing the private key, but I do not want to use hardcoded keys for this encryption.
What are some common practices followed by applications that use SSL?
source to share
To make sure we have the terminology straightforward, a "SSL certificate" in common language does indeed have two components:
- Public certificate
- Private key
The public component of the certificate is signed by the chosen CA (certification authority) and can then be freely redistributed. It doesn't need to be protected or encrypted and will indeed be sent to clients that connect to your server as part of the SSL negotiation.
The private key component must be protected. In most cases, this is simply stored as an encrypted file on the server. High-end private key storage solutions use specialized encryption equipment (HSMs - Hardware Security Modules). They range from smart card solutions to multifunctional network devices with m / n controls and more. Etc. There are risks (not to mention costs) associated with HSM that I will not cover here.
Many applications simply save the private key to disk. There are several options for protecting a key file:
- Rely on the security of system and file permissions (i.e., don't encrypt the private key). For example, most ssh daemons do this.
- Use whatever mechanism your server provides to encrypt the file. Password protected encryption is standard on most web servers. (If you are using your own OpenSSL API, choose one of the obvious native key formats).
As always, there is a trade-off between security. Specifically, if you are using password protected encryption in the private key file and you experience an unexpected restart of the application (such as a power outage), then someone would have to be available to provide the password to the application when it restarts. Storing the password in a file that is read by system initialization scripts (as recommended by at least two web server vendors) says little about real security. It is not recommended to leave the private key file unencrypted, but if you are the only administrator / technician in a small store, you should definitely think about what might happen if the server reboots when you are unavailable and what costs you might have in your company ,
source to share
not really sure what you are trying to ask. the server certificate is sent to you, the client; you verify the certificate by verifying its signature (use SHA-1, not MD5, MD5 has been cracked.) The key you have from the CA is the public side; The CA and the owner of the server's certificates keep their private keys. You can verify the certificate because the public key is enough to decrypt a message that was encrypted with the private key. Therefore, you do not need to worry, on the other hand, about keeping the certificate encrypted.
source to share
I am confused as to how I should secure the server certificate.
You don't need to secure the server certificate. This is a public document
I would like to encrypt the server certificate containing the private key
The server certificate does not contain the private key.
but I don't want to use hard encrypted keys for this encryption.
You don't need to do encryption. The only server resource that needs to be protected is its private key, which is completely different from its certificate. In the case of OpenSSL, it might even be a different file.
source to share