PGP Encryption Management Server Unable to Sign with SMIME Certificate: Item Not Found
search cancel

PGP Encryption Management Server Unable to Sign with SMIME Certificate: Item Not Found

book

Article ID: 236768

calendar_today

Updated On:

Products

Desktop Email Encryption Drive Encryption Encryption Management Server Endpoint Encryption File Share Encryption Gateway Email Encryption PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK

Issue/Introduction

When attempting to send an SMIME-signed and encrypted message, the email is encrypted, but not signed with the following error:

 

"SMTP-00152: error getting signing key for user"

Resolution

The reason this error message comes up is due to the signing portion of the key becoming expired.

The PGP Encryption server has a strict policy for keys, both SMIME or PGP.  When keys are not being used, there is a period where the keys can remain inactive, but still valid.  When the threshold is reached, the key will become expired.

The expired key remains on the PGP server until the user uses the key again.  Keys will get used if the PGP client checks in with the PGP server, or if a user sends an email through the PGP server if configured in the mailstream.

 

This has to do with the key renewal policy as outlined in the following screenshot for the Key Properties on the PGP server (Under the Consumers tab, choose the Consumer Policy, then edit the Key settings):

The first option "Auto Renew Keys Every" determines how long a key is considered "valid":

The default value is "2 weeks", which means that as long as the user is active within 14 days, then the key remains valid.  If the user hasn't contacted the PGP server in 14 days, the key will expire.

The next value for this is the "Stop Renewing After" interval:

This value means that if a key goes over the two-week period and becomes expired, if the user checks back in with the PGP server within 3 months, the key can be renewed and will no longer be expired.  

If the keys become expired after the two-week interval, and the user still doesn't check in to the server within three months, then a new PGP key will be generated.


Note for SMIME Scenarios:  The PGP Server can generate an Organization Certificate and in turn will create smime certificates for each of the end users managed by the PGP server.  This Organization Certificate is a "Self-Signed" certificate and will not be trusted by external entities.  This means that unless someone trusts the Organization Certificate, all the user certs will be considered invalid based on the fact that the issuer is itself and not a trusted CA.  This can work just fine as long as you trust the PGP's Organization Certificate.

For scenarios where the SMIME certificates are actually generated by a trusted CA, such as Digicert, the renewal periods are not applicable as the CA will determine these renewal periods.  This article is geared only for PGP keys, or the self-signed certificates using the Organization Certificates. 

 

 

Recommendations for Scenarios: 

If you are seeing keys become expired sooner than you would like, we recommend extending this parameter to a higher value. 

Each environment is different and should be configured accordingly so we will provide you with two examples for how you could configure your policies.

 

Scenario 1: Default Parameters
In the default configuration, the renewal period is two weeks.  This is the most aggressive scenario and makes some assumptions that the users will be frequently contacting the PGP server and is especially more common for Email Encryption scenarios where users are encrypting emails on a fairly regular basis.  The default settings will work generally, but you will likely see many users are grayed out if they do not contact the server within the two-week interval.  

For Drive Encryption scenarios, the PGP keys are not really used and so the users may become grayed out, even if their accounts are still valid.  Scenario's two or three may be better suited for these types of environments.

 

Scenario 1: Two Months
The recommendation is to consider how long a user may be inactive, but still a valid user.  If someone goes on vacation for 3 weeks commonly, then 2 weeks may be too aggressive. 

If it is common for a user to be gone as long as 4-6 weeks at a time but still return to work, then consider changing the "Auto Renew Keys Ever" parameter to two months.  This will mean that as long as users will communicate with the PGP server within 2 months, their key will never become expired.  This will ensure no keys become expired needlessly.

Important: Whatever the "Auto Renew Keys Ever" parameter is set to, make sure the "Stop Renewing After" interval is set to a higher value so that the renewal period does not outlast the stop-renewing period.  In this example, 2 Months is set and so we will set the "Stop Renewing" parameter to "3 months of Inactivity":

Scenario 2: Six Months
 If you would like to have all your keys remain on the server and be valid, but you have some users who may be gone for longer periods of time, consider moving the value up.  Especially in environments where Drive Encryption is being used, the PGP keys may not be as critical, and preventing the keys from expiring will prevent users from appearing as "invalid" (Grayed out in the UI).

For example, if you have users who are gone for up to 5 months, then consider setting the renewal period to six months.   

Important: If you set the renewal period to six months, then set the "Stop Renewing" period to a higher value.  In this example, we will use "1 Year of inactivity"  
In this example, as long as users connect to the server within 6 months, their keys will never expire.  

 

Additional Information

157933 - PGP Encryption Server user keys are valid for only two weeks

ISFR-2159