I am trying to setup Network Prevent for Email and there seems to be a disconnect in the documentation regarding some of the default keystore passwords.
Here are some simple steps to recreate the problem.
1. Generate a new keystore as you normally would after install (install guide pg 47 or admin guide pg 315).
This gives you a new enforce.*.sslKeyStore for the enforce server and a monitor.*.sslKeyStore file for your detection servers. I've tried this both with a single cert for the detection boxes and using the aliases file to create individual ones for each server. It doesn't matter which way you go.
2. On your Network Prevent for Email box, following the steps in the MTA integration guide (pg 34) I go to change the password on the newly generated keystore. Now technically you could leave this password the same, assuming you know it, but generally you want to change it. You need to know it for step 3 and 4.
keytool -storepasswd -new <mynewkeystorepassword> -keystore c:\Vontu\Protect\keystore\monitor.blahblah.sslKeyStore -storepass dummypassword
This command now fails with "Keystore was tampered with, or password was incorrect". I've tried:
dummypassword, protect, Protect, prevent, Prevent all without success. What password is the sslkeytool chosing for these new keystores?
3. Now you would do the generate keypair step on pg 35. It requires you to know the keystore password and make sure you certificates are using the same password (-storepass) for the key password (-keypass). You can't run this command if you don't know the password from step 2, either the one you changed it to, or the default if you didn't.
keytool -genkeypair -dname "dname_string" -alias smtp_prevent -keypass key_password -keystore c:\Vontu\Protect\keystore\prevent.ks -storepass store_password -validity expiration_days
4. Now you would import the public certs from your upstream/downstream MTA's depending upon your config. Again without the keystore password you can't do this.
So in the end you essentially can not use Network Prevent for Email with TLS appropriately configured if you are using anything other then the prevent.ks default keystore. Now what company who is serious about security is going to use the default keystore where everyone else has that private key and can decrypt data protected by it.
Can someone help me out here? Is there an undocumented default password that sslkeytool is chosing other then dummypassword?
Thanks!