Implementing digital signatures in Exchange/Outlook environment is not a very complex. However, it requires that you understand how this technology work, and also must have some infrastructure background implemented.
Digital signatures actually protect the content integrity. They don’t provide any protection in a meaning that content of the message can’t be intercepted and read by someone else. However, if the content is altered during transport, digital signature will alert you on this.
When an author digitally signs a document or a message, the operating system on his machine creates a message digest which ranges from between a 128-bit and to a 256-bit number. It is generated by running the entire message through a hash algorithm. This number then is then encrypted by using the author’s private key, and then it is added to the end of the document or message.
When the document or message reaches the recipient, it will go through same hash algorithm as when it was digitally signed. Also, the recipient uses the author’s public key to decrypt the digest that is added to the message. After it is decrypted, it is compared to the digest that the recipient has generated. If they are the same, the document or the message was not altered during transport. Also, if the recipient is able to decrypt the digest by using the author’s public key, this means that the digest was encrypted by using author’s private key, and that confirms the author’s identity. At the end, the recipient also verifies the certificate that was used to prove author’s identity. During this check, the validity period, CRL, subject name, and certificate chain trust also are verified. Make sure that certificates that you use for digital signatures have valid CDP and AIA locations defined.
To implement digital signatures in internal communications, you just need to issue certificates based on the User template. This certificate template is present by default on each Windows Server CA. Of course, you can also use a custom template for this, or you can use smart card certificates for digital signature. This is actually pretty common if smart card infrastructure is deployed. You must issue certificates to all users that who use digital signatures, as authors (don’t need to have one just to read digitally signed message). You can issue the certificate without any user intervention if you use autoenrollment. Also, users must use an application that supports content signing. The digital signatures are ready to be used after the certificate is issued and configured in the application. Certificate for digital signature will be mostly automatically configured in Outlook, so the end user will not need to perform any configuration. If you want to use digital signature in OWA, you will need to install latest S/MIME controls. For mobile platforms and digital signatures, things are not so simple. At the moment, most mobile platforms do not support functionality of digital signature in an email (although ActiveSync does support it on protocol level).
However, if you want to send digitally signed content outside of your organization, you can experience CA trust issues. In this scenario, a recipient is not in the same domain as the author, so it does not trust a the CA that issued a the certificate for the digital signature. Although this kind of digital signature will still be valid from the aspect of content protection perspective, an application being used will probably generate a warning on the recipient side.
If you have a need to send digitally signed content to recipients outside of your organization, I recommended that you buy certificates from a public, globally trusted, CA.