[openssl-users] regarding automating certificate management process
jb-openssl at wisemo.com
Sun Jun 12 20:49:24 UTC 2016
On 12/06/2016 15:52, R-D intern wrote:
> I have implemented ssl for tcp ad HTTP as well i.e ssl security for
> tcp ad http servers. I have created self- signed certificate for CA and
> server and client certificates using the self- signed CA certificate.But I
> would like to know the process of automating certificate management . For
> 1. My certificates and private keys are stored on my local machine in .pem
> format .I need to make the files unreadable so as to avoid mischief .Hence I
> create a .pfx file and install that on my windows certificate store, But I
> would require the cert and key paths in the server program. How do I open
> windows store and extract certs and keys only to retrieve those for my
> server program and not store the certs and keys on my local machine or file
> ? Is this the procedure how keys and certs are secured on server machines ?
> if not , what is the procedure, please elaborate.
Although you can (insecurely) set the Windows key stores to allow
out the private key, this should never be done except when temporarily
a key that is not intended to stay there (like when using Microsoft
create a PFX file for somewhere else).
The standard way is to make your server (or non-server) program call the
Windows CryptoAPI functions to perform the operation using the key, without
actually revealing the key itself. Microsoft programs such as IIS, IE
AD LDAP server typically do this by default (to the point of requiring
be imported into the Windows store to be used at all).
OpenSSL based programs can use a key stored in the Windows key store by
the "CryptoAPI Engine" and instructing it as to which key in the Windows
store it should use.
> 2. One more concern is , if I export the .pfx file for my server program, I
> need to also give a password with which the .pfx file import had been done
> on the windows cert store and at some point in time , if the certificate
> renewal is to be done and the system admin is a new one, a new password will
> be assigned and on next export of .pfx file to server program, how do I
> assign new password? Is this the process that needs to be followed?
> Please reply,
PFX files are generally a bad way to store keys, the format is
botched design originally intended as a means to transport personal keys
one Browser installation to another. While a PFX file conveniently
private key along with its public key and a certificate chain, the
done is not exactly impressive, often defaulting to
outdated NSA-friendly 40-bit encryption as permitted in crypto products
exported from the US to the rest of the world in the 1990s.
Encrypting a private key PEM file with the options available in modern
programs such as OpenSSL tends to be a lot better, though I do know of even
stronger protections even for file based private key storage.
However ultimately, unless you have access to some super-protected storage
locations where the server can store/retrieve a "password" but not a
private key, giving the server limited access to an unencrypted private key
PEM file is not significantly worse than giving the same server access
encrypted private key and a non-encrypted decryption password for that key.
A common way to restrict the servers access to the private key file on non-
Windows computers is to have the server process start under a privileged
account (such as UNIX root), load the private key and open a few other
privileged resources (such as the ability to listen on TCP port 443), then
irreversibly drop those privileges before processing any data coming from
outside or other dubious places. To access the secret or privileged stuff
again, a privileged sysadmin would have to stop the server program and
it again, causing it to load the stuff into memory and dropping privileges
again as before (Same thing happens on reboot).
On Windows the "irreversibly dropping privileges" feature is missing in
design, so another option when designing or modifying a server
to have a privileged process (such as a service launched under
LocalSystem account), retrieve the password from an ACL protected
then pass it securely to the actual service process launched under a less
privileged account using a call such as CreateProcessAsUserW() or
CreateProcessWithLogonW(). Note that neither the command line nor the
environment variables are secure because they are exposed to lesser
administrators via the WMI service, as used by e.g. the Task Manager UI.
As for letting new administrators access secret passwords known to the
administrators, this issue is in no way limited to certificates and
a consistent solution in any well-run organizations. One way would be
these passwords in a heavily protected (and encrypted) file such as one
quality off-line password manager program, while having the master
password for that file written down in an envelope in a locked physical
(its kind of hard to hack a piece of paper in a locked non-electronic
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
More information about the openssl-users