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
