none
Setting up a "simple" S/MIME Certificate Issuer/CA properly RRS feed

  • Question

  • Hello, this is actually my first foray into PKI and Windows server. I've been tasked to research options for setting up PKI for AD users to allow them to encrypt their emails.

    I think I have everything going somewhat well. I duplicated Exchange Signature and Exchange User templates separately. I set each of them to pull AD information to populate the certificate and I set ACLs for all Domain Users to auto enroll. I then added the GPO for auto-enrollment in the default domain policy since this is all my test environment.

    Now I have 3 questions:

    1. When I log into a user they don't get the certificates until after I go to certmgr and task them to automatically enroll and retrieve certificates. Is there a way to automate this for when the user logs into the computer?

    2. Is there a way to sign your root CA's certificate with a trusted third party certificate? I'm worried that when the users email with our certificates to outside clients, they either won't be trusted or they won't even be able to decrypt it.

    3. Am I doing any of this right?

    Thursday, November 21, 2019 6:07 PM

Answers

  • I duplicated Exchange Signature and Exchange User templates separately

    if you are planning both signing and encryption, it is ok to have single certificate based on Exchange User. It allows signing and encryption.

    1) have you enabled Certificate Autoenrollment policy in User configuration?

    2) It is possible, but extremely expensive. You can read my blog post on this subject: Certification Authority Root Signing. Most likely, it is not for you.

    3) almost. Any kind of user encryption, whether it is emails, EFS or anything that users encrypt in long term requires key archival and recovery procedure. Imagine if someone looses his certificate. All encrypted emails in user's mailbox will be lost, because you no longer have a key to decrypt them. I would strongly recommend to invest in KRA infrastructure in your scenario. Reference Microsoft Whitepapers: Key Archival and Management in Windows Server 2003 and Key Archival and Management in Longhorn Beta 3.

    p.s. Microsoft has removed mentioned whitepapers from their website, so I'm hosting them on my website.

    Disclaimer: This document is provided for informational purposes only and I, Vadims Podans make no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. I’m claiming no patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    • Marked as answer by Slinkilicious Friday, November 22, 2019 5:03 PM
    Thursday, November 21, 2019 8:33 PM

All replies

  • I duplicated Exchange Signature and Exchange User templates separately

    if you are planning both signing and encryption, it is ok to have single certificate based on Exchange User. It allows signing and encryption.

    1) have you enabled Certificate Autoenrollment policy in User configuration?

    2) It is possible, but extremely expensive. You can read my blog post on this subject: Certification Authority Root Signing. Most likely, it is not for you.

    3) almost. Any kind of user encryption, whether it is emails, EFS or anything that users encrypt in long term requires key archival and recovery procedure. Imagine if someone looses his certificate. All encrypted emails in user's mailbox will be lost, because you no longer have a key to decrypt them. I would strongly recommend to invest in KRA infrastructure in your scenario. Reference Microsoft Whitepapers: Key Archival and Management in Windows Server 2003 and Key Archival and Management in Longhorn Beta 3.

    p.s. Microsoft has removed mentioned whitepapers from their website, so I'm hosting them on my website.

    Disclaimer: This document is provided for informational purposes only and I, Vadims Podans make no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. I’m claiming no patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    • Marked as answer by Slinkilicious Friday, November 22, 2019 5:03 PM
    Thursday, November 21, 2019 8:33 PM
  • I wasn't expecting Vadims to show up here. I've been referencing your website since I was tasked this whole thing.

    I duplicated Exchange Signature and Exchange User templates separately

    I thought this was best practice. The idea came from: "S/MIME certificates autoenrollment" question by Oleg.Kovalenko on this site.

    1. I have enabled auto-enrollment in computer and user configurations in the default domain GPO. That was what fixed my first problem of the certificates being unavailable for enrollment. I also tried following the instructions on vkernel.ro "Set Up Automatic Certificate Enrollment (Autoenroll)" article, which didn't change anything.

    2. After reading that article I agree. It's only around 30 people that need these certificates on a never-regular basis. Would it be troublesome for clients receiving emails from my office to validate our encryption certificates?

    3. I'll have to fire up the VM again tomorrow and work on the archival process. Have they updated key archival for server 2016 to still keep them non-exportable while still archivable?

    Sorry for the formatting. This account isn't verified so I couldn't add links and the emergency verification thread crashed my browser.

    Friday, November 22, 2019 2:46 AM
  • I thought this was best practice.

    it adds an unnecessary complexity. Separate templates are used when some users needs only to sign emails, without encryption. To those users you will use Exchange Signature based template.

    Would it be troublesome for clients receiving emails from my office to validate our encryption certificates?

    they will get "signature cannot be validated" error line in outlook, but emails will be delivered.

    Have they updated key archival for server 2016 to still keep them non-exportable while still archivable?

    was it ever an issue? You can have non-exportable private keys with an ability to archive them. I'm not aware about changes in this aspect.


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    Friday, November 22, 2019 10:25 AM
  • Okay. I think I do want to keep the separate templates as some might just need to sign the email without encrypting it. Maybe I should switch the template instead to a basic signature template so users can sign other files and documents?

    Besides the "signature cannot be validated" line, emails will be encrypted and also readable to outside clients? I think they can live with that.

    I jumped the gun a little on reading the Key archival and management in WS 2003. I saw exporting keys in the instructions and got worried.

    Friday, November 22, 2019 3:09 PM
  • I've come across another forum that mentions only the encryption keys need archived. That makes sense.

    How long until these certificates need renewed then. Maybe a year for the signature and a few months for encryption?


    Friday, November 22, 2019 4:57 PM
  • Maybe I should switch the template instead to a basic signature template so users can sign other files and documents?

    then you will need to add corresponding usages in Application Policies extension. I mean, Document Signing, etc.

    Besides the "signature cannot be validated" line, emails will be encrypted and also readable to outside clients?

    yes. One point to keep in mind: emails are encrypted with *recipient's* certificate, not sender's. If you would send me encrypted email, you will use *my* public certificate to encrypt the message.

    I've come across another forum that mentions only the encryption keys need archived. That makes sense.

    that's correct. Signing and authentication certificates don't need key archival. If certificate is lost, just reissue signing certificate.

    How long until these certificates need renewed then. Maybe a year for the signature and a few months for encryption?

    it depends on your practices. For generic cases, I would give 2 years to both. I would avoid to have too frequent encryption certificate change, because you will have to carry all encryption certificates in order to read all encrypted emails. This will quickly become a very fragile maintenance solution.


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    Friday, November 22, 2019 7:26 PM
  • Thanks for all the help. I feel like I'm getting closer.

    The only confusing part is now how to disseminate the public keys when a user emails a client. I forgot that public keys of the target are used. If one of my users opens outlook 2010 and turns on encryption for all outgoing emails, what is outlook searching for? In Office 365 there's just an encrypt button.

    I don't have office 365 installed anywhere so I just have to go off what I've seen

    Friday, November 22, 2019 11:05 PM
  • what is outlook searching for?

    for recipient's public certificate. And won't send if there is no such.


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    Saturday, November 23, 2019 8:20 AM
  • Okay, example to make sure I understand:

    In Outlook 2010 the trust center allows you to "encrypt contents and attachments for outgoing messages" and "add digital signature to outgoing messages".

    This means that when I click for encryption, outlook is going to look for my recipients public certificate; upon finding none I should get an error but can continue without encryption. Clicking add signature uses a local certificate with an email signature policy, this is imported right below the top options in Digital ID.

    I guess I need to re-look over all my architecture I was drawing out. Most of my users will be emailing random clients that may not have public certificates for outlook to encrypt the messages with. If clients email my users I would need some form of public key dissemination on an outward facing server? That might be doable for me in another week of researching.

    Monday, November 25, 2019 9:50 PM
  • This means that when I click for encryption, outlook is going to look for my recipients public certificate; upon finding none I should get an error but can continue without encryption. Clicking add signature uses a local certificate with an email signature policy, this is imported right below the top options in Digital ID.

    that's correct.

    If clients email my users I would need some form of public key dissemination on an outward facing server?

    Often it is done by exchanging with signed emails and adding senders to contacts. Along the sender details a signing certificate is added to contact properties for future encryption. And then send encrypted email usin outlook contacts (not outlook cache as it may mess with cache and contacts).


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    Wednesday, November 27, 2019 3:32 PM
  • Hm. I'm not sure how effective sending signed emails to clients will be for us now. We could sign outgoing emails pretty easily, but the problem comes with the encryption.

    Since we deal with thousands of clients, probably none of them would have a public key for us to send with. Then, since everyone uses different email clients, there's no telling if they could encrypt messages back to my organization.

    I wonder how Microsoft or the government deal with sending sensitive data by email to people.

    --added--

    Is one way encryption a thing? If my users email a client with a signed email, can the client encrypt replies back to us? This may be a decent compromise as long as my organization isn't the one emailing PII.
    Monday, December 2, 2019 8:44 PM
  • Crazy. Office 365 can get azure information protection that does pretty much everything I've been needing. It says it uses the recipients email address as their public key. How can they do that? I know at this point they are dealing outside of certificates
    Monday, December 9, 2019 9:13 PM