According to this post: Update SSL certificate - forum.mailenable.com MailEnable picks up the first matching certificate from the local Machine store (under My/Personal) that matches your domain. In their example script they modify the stored certificate permissions so that the MailEnable user (IME_SYSTEM) can access the private keys.
Here is an example script which might work. It takes our most recent certificate and updates the access to the private key so the IMS_SYSTEM user can read it, then it restarts the Mail Enable service: [See edited version below]
Add a deployment Task (most likely the powershell scripting task) with your own custom script to apply the SSL certificate to your server (in this case, MailEnable). Scripting | Certify The Web Docs - you can run your task repeatedly to develop/test it without re-requesting your certificate. You will want to apply the SSL configuration changes, then you will probably want to restart the MailEnable service (as per this example).
Thanks, here is another version with a fix for a mistake getting the correct certificate Thumbprint. If the “Some or all identity references…” error persits, check your Mail Enable service account name. This script is assuming “IME_SYSTEM”, but it could be something else.
param($result)
# Script to allow MailEnable user "IME_SYSTEM" to read private key for the given cert
# based on code example from https://mailenable.com/forum/viewtopic.php?f=4&t=40948#p115342
# Specify the user, the permissions and the permission type
$permission = "IME_SYSTEM","Read,FullControl","Allow"
$thumbprint = $result.ManagedItem.CertificateThumbprintHash
# get the stored certificate (must be in My store, not WebHosting)
$cert = Get-ChildItem -Path cert:\LocalMachine\My\$thumbprint
# configure file system access rule
$accessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $permission;
# Location of the machine related keys
$keyPath = $env:ProgramData + "\Microsoft\Crypto\RSA\MachineKeys\";
$keyName = $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName;
$keyFullPath = $keyPath + $keyName;
try
{
# Get the current acl of the private key
$acl = (Get-Item $keyFullPath).GetAccessControl('Access');
# Add the new ace to the acl of the private key
$acl.AddAccessRule($accessRule);
# Write back the new acl
Set-Acl -Path $keyFullPath -AclObject $acl;
}
catch
{
throw $_;
}
# optional, restart of Mail Enable service
Restart-Service -DisplayName "MailEnable*"
So the script is currently set to update settings for “IME_SYSTEM” (not “IME_ADMIN”) so you need to figure out what user account your Mail Enable service runs as then target that account in the script instead (i.e. change IME_SYSTEM to the correct user account).
OK. Try just changing the script to use IME_ADMIN that should at least work without error, then see if the mailenable certificate settings UI can see the certificate.
We are currently running the free version standard of MailEnable so that user doesn’t exist. Only if we upgrade then we will have it. Well that is what I read of from their text here.
So I suppose will attempt to run the script with IME:ADMIN instead as you suggested…
Great, so the script will run every time the certificate automatically renews, which by default is every 30 days (you can change this under settings). The Certify background service controls the actual automatic renewals so there is no schedule to setup.