[openssl-users] regarding automating certificate management process

[Jakob Bohm]

On 12/06/2016 15:52, R-D intern wrote:
> Hello,
>          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
> example:
> 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 
reading back
out the private key, this should never be done except when temporarily 
storing
a key that is not intended to stay there (like when using Microsoft 
tools to
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 
and the
AD LDAP server typically do this by default (to the point of requiring 
keys to
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 
using
the "CryptoAPI Engine" and instructing it as to which key in the Windows 
key
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,
> Best,
> R-DIntern

PFX files are generally a bad way to store keys, the format is 
essentially a
botched design originally intended as a means to transport personal keys 
from
one Browser installation to another.  While a PFX file conveniently 
stores a
private key along with its public key and a certificate chain, the 
encryption
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 
full size
private key, giving the server limited access to an unencrypted private key
PEM file is not significantly worse than giving the same server access 
to an
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 
start
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 
the OS
design, so another option when designing or modifying a server 
application is
to have a privileged process (such as a service launched under 
LocalService or
LocalSystem account), retrieve the password from an ACL protected 
registry key,
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 
previous
administrators, this issue is in no way limited to certificates and 
should have
a consistent solution in any well-run organizations.   One way would be 
to keep
these passwords in a heavily protected (and encrypted) file such as one 
from a
quality off-line password manager program, while having the master 
decryption
password for that file written down in an envelope in a locked physical 
safe
(its kind of hard to hack a piece of paper in a locked non-electronic 
safe over
the Internet...).


Enjoy

Jakob
-- 
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