Stefan,

Everything has been working great since we last spoke (Version 2.7.8), until InfoSec decided to change how the Certs were created.  Now they come with a little bit of code in the .key file before the Hash.. when I put the new .CRT and .KEY in the SSL folder I am asked on starting Elogd to provide a "PEM PassPhrase".  As you can expect, if you do not enter one, or the incorrect one, it does not just turn off SSL, it exits the program.  The key begins like this in the new versions:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,ACF4A8B263EAA51D

(that little encode piece on the end is not the actual one in the key.  I am assuming it is a passphrase key so it will know what the right passphrase is that should be entered.

We are assuming that this is the "Install password" they have set up to use to install the certs on all of the IIS servers we have.  If that is indeed the case.. Does elog save this passphrase somewhere?  does Elog save it in the registry? does it save it encrypted? Or with access security permissions set on the keys?  I have a feeling that the answer to most of this is probably "no", but to know where we go from here, that is the place to start.

Thanks

Chuck

There is sometimes a problem with substitutions like "Execute delete = echo $message id".

It seems the problem is that if you delete a logbook entry that is not created with the current logbook attributes, the substitution variables are replaced with the variable name, and not the variable value.

In this example, according to the log file it becomes SHELL "message id" instead of SHELL "234", if the logbook entry is 234.

Soren

I tried to reproduce it, but it always worked for me. So I need a step-by-step instruction from you on how to reproduce the problem, ideally starting from the demo logbook from the distribution. Only if I can reproduce the problem, I will be able to fix it. 

 Since we updated to 2.7.8 we've found a problem.

Previously, when we used 

Subst on reply subject = Re: $subject

Will elog defer user identification and authorization to the ssl engine of a *local* Apache proxy?  I'd like to try elog in a site that requires the service port positively authenticate and identify users via smartcard certificate ID.  Per SOP they have Apache+mod_ssl setting SSLUserName=SSL_CLIENT_S_DN_CN which sets both the SSL request object's "user" field and the REMOTE_USER environment var relative to the mod_ssl's session's process group leader.  Users auth with Apache's mod_ssl as a single-signon replacement for web apps which have traditional native, internal user accounts/passwords, but those passwords are subsumed by the Apache/smartcard/mod_ssl setup.  The web apps define internal accounts matching the users' cert IDs but do not allow any management of the [unused] passwords.  Can elog do this?