- Windows Server 2016 Migrate Certificate Authority
- Windows Server 2016 Certificate Authority Application
- Windows Server 2016 Certificate Authority Online
This is the fifth part of a seven-part series explaining and setting up a two-tier PKI with Windows Server 2016 in an enterprise SMB setting.
*Note* (16 May 2017): This page is currently in progress, is unfinished, and likely contains errors. I published it in this state due to time constraints, and will be working on it over the next week until it’s finished.
Because of the long time period between part 4 and part 5, I had to recreate my demonstration lab. Everything is functionally the same, but you may notice some different IPs or other minor changes.
Part 1 (Informational)
Part 2 (Getting Started & IIS Web Server Configuration)
Part 3 (Standalone Offline Root CA Configuration)
Part 4 (Enterprise CA Configuration)
>>> Part 5 (Distributing Certificates & AutoEnrollment) <<<
Part 6 (Additional Configuration)
Part 7 (Troubleshooting & Clean-up)
Part 2 (Getting Started & IIS Web Server Configuration)
Part 3 (Standalone Offline Root CA Configuration)
Part 4 (Enterprise CA Configuration)
>>> Part 5 (Distributing Certificates & AutoEnrollment) <<<
Part 6 (Additional Configuration)
Part 7 (Troubleshooting & Clean-up)
To help with the layout and navigation of these longer pages, use the Table of Contents below:
Table of Contents
- 1 Certificate Templates
- 1.1 Creating your (S/MIME) Certificate Template
Now that you have the IIS, Root CA, and Enterprise CA servers basically set up, it’s time to create or distribute certificates to users and devices. But, before we can do that, we must create the templates from which the certificates will be made.
There’s a ton of reasons you would want to distribute user and computer certificates, and a ton of certificate templates you could configure. To name a few popular examples, you could have a template for the following purposes:
- Web Server SSL certificates
- Email S/MIME certificates for digital signatures and encryption
- One for digital signatures
- One for encryption
- Smartcards
- IPSec
- File encryption
- …etc
If you are a small or even medium size business, require a simple PKI, and don’t want to deal with the extra administration of multiple certificates, you could combine them a little if you are using strong encryption algorithms. This of course depends on a number of factors, so don’t just go ahead and do it…
For example, lets say that due to new email security concerns, you need to require that all emails from company users are digitally signed and encrypted. You could do that with a single certificate. Best practice may suggest that you use separate certificates; one for digital signatures, and one for email encryption. You don’t have to. Will it matter? Not likely, but it can.
However, your company may have legal reasons to do so, and may be required to separate them! You may also be high-risk. Always find out first! The main reason for separating them is to spread risk. If your encryption key was compromised, not only could the attacker decrypt your emails, but they could also impersonate you by using the same key to digitally sign emails as you! The same idea goes for whatever else the certificate is used for. Another two reasons, are that you may also want to set certain certificates to expire sooner or later than others… or for archival (escrow) purposes. There are definitely other reasons, but for now you get my point.
For the purpose of keeping this guide simple and still useful, I’ll guide you through creating a single template for email (digital signatures and encryption) certificates, and a template for one-off Web Server SSL certificates. Once you can do these, you can easily make and distribute certificates for any purpose, such as those listed a bit above.
Creating your (S/MIME) Certificate Template
On the server issuingCA, we will duplicate a preexisting user certificate template and configure it to our needs for digitally signing and encrypting email.
Office home and student license. Microsoft Office 2010 Home and Student Free DownloadMicrosoft Office 2010 Home and Student Single Link for Windows.
Duplicate a user certificate template
- Open up Certification Authority manager.
- Right-click on Certificate Templates and select Manage.
- Right-click on the User template and click Duplicate Template.
- In the Compatibility tab, select your appropriate compatibility levels.
- In my testing and lab environment, nothing is running below Windows 10 or Windows Server 2016, so I selected appropriately. Your environment may be different, choose your settings intelligently.
- In my testing and lab environment, nothing is running below Windows 10 or Windows Server 2016, so I selected appropriately. Your environment may be different, choose your settings intelligently.
- In the General tab:
- Type a display name for your new template.
- Set a validity period. Two years is a good standard that meets most usage requirements.
- Renewal period sets the amount of time before the validity period expires in which the certificate will be renewed. Six weeks is sufficient for a two year validity period.
- CHECK Publish certificates in Active Directory.
- CHECK Do not automatically reenroll if a duplicate certificate exists in Active Directory.
- Some reasons you want this enabled is in the case users will log on to more than a single computer, and if you don’t want users to keep getting multiple certificates via auto-enrollment.
- If the certificates are stored in AD, we’ll be setting a Group Policy to have their certificates automatically “follow” the user no matter which computer they log on to in the domain.
- In the Request Handling tab:
- CHECK Archive subject’s encryption private key.
- We’ll be enabling key archiving later, before we start distributing certificates with this template. You may or may not want to do this in your production environment due to policies or legal reasons. Check first! Generally, it should be okay, and is nice to be able to recover a users private key in the case it is lost.
- We’ll be enabling key archiving later, before we start distributing certificates with this template. You may or may not want to do this in your production environment due to policies or legal reasons. Check first! Generally, it should be okay, and is nice to be able to recover a users private key in the case it is lost.
- CHECK Archive subject’s encryption private key.
- In the Cryptography tab:
- Provider Category, select Key Storage Provider.
- Algorithm name, verify RSA is selected.
- Minimum key size, change it to 4096.
- Select Requests must use one of the following providers:
- Select Microsoft Software Key Storage Provider
- Request hash, select SHA256. Legacy clients may not work with SHA256 and may require updates, or your environment may need CSP. Check first.
- Note that this area may be greyed out. You should be using Key Storage Provider. You can check what is used in the CA Properties here:
- In the Subject Name tab:
- Subject name format: Common name
- Check: Include e-mail name in subject name
- Verify checked:
- E-mail name
- User principal name (UPN)
- In the Extensions tab:
- Select “Key Usage“, and then click the Edit button
- Check the box that says “Allow encryption of user data“.
- Check the box that says “Allow encryption of user data“.
- Select “Key Usage“, and then click the Edit button
- In the Security tab:
- Select each user/group at the top and verify the following are checked:
- Authenticated Users: Read, Enroll, Autoenroll
- Domain Users: Read, Enroll, Autoenroll
- If there are any users in the domain you do not want to have autoenrolled, you can create a group in Active Directory, add the user(s) to it, then add that group in the Security tab above, checking the Deny box for Autoenroll for that group.
- Select each user/group at the top and verify the following are checked:
- Click Apply, then click OK.
Publishing your (S/MIME) Certificate Template
Publishing a certificate template makes it available for use. To publish your above S/MIME certificate template (or any other certificate template), follow the below steps.
- In Certificate Authority manager, click on Certificate Templates.
- Then right-clickCertificate Template, go to New, and click Certificate Template to Issue.
- Scroll down to find the template you created: User Email AutoEnroll, and click OK.
- asdf
Autoenrollment will not automatically hand out certificates to users until we create and configure a GPO that is distributed to all domain computers. But before we do that, we need to enable private key archiving.
… article in progress …
This is the first part of a seven-part series explaining and setting up a two-tier PKI with Windows Server 2016 or Windows Server 2019 in an enterprise SMB setting, where the hypervisor (host) is running the free Hyper-V Server 2016 or Hyper-V Server 2019, all Certificate Authorities (CA’s) and IIS servers are running Windows Server 2016 or Windows Server 2019.
This series was designed for those who are about to, or already have, implemented a production enterprise PKI and to serve as a guide through the process in a real-life manner. Many other guides are similarly designed, but are more geared towards test environments, using defaults, and not exactly considering real-life scenarios and practices. My aim is to tie up any loose end questions or needed help regarding the deployment, or to act as a template when trying to troubleshoot existing deployments.
>>> Part 1 (Informational) <<<
Part 2 (Getting Started & IIS Web Server Configuration)
Part 3 (Standalone Offline Root CA Configuration)
Part 4 (Enterprise CA Configuration)
Part 5 (Distributing Certificates & AutoEnrollment)
Part 6 (Additional Configuration)
Part 7 (Troubleshooting & Clean-up)
Part 2 (Getting Started & IIS Web Server Configuration)
Part 3 (Standalone Offline Root CA Configuration)
Part 4 (Enterprise CA Configuration)
Part 5 (Distributing Certificates & AutoEnrollment)
Part 6 (Additional Configuration)
Part 7 (Troubleshooting & Clean-up)
Table of Contents
- 3 The Design
This is the most important step, as it determines how you do everything moving forward.
You must plan carefully, taking into consideration where your PKI implementation may lead down the road. If you need to make changes later (or sooner), or you found you made a mistake or need to make a change after you have already distributed certificates to users and devices, you will most likely need to re-deploy those certificates. It depends on what the mistake or change is, of course, but this is usually a huge pain. Now don’t worry, if it happens or has already happened, I will show you how to get started cleaning it up.
Here are a couple common questions to ask, when using your own certificates for these instances:
- Will you require public access to your CA services?
- S/MIME certificates for e-mail digital signatures and encryption
- If you plan to use it in any way outside of your LAN, such as with Office 365, external users, Outlook clients off-LAN, etc.
- S/MIME certificates for e-mail digital signatures and encryption
- Will you be implementing DirectAccess?
- Will you be implementing IPsec or another type of network infrastructure that requires certificates?
- Will you be implementing Single Sign-On (SSO) or Active Directory Federation Services (AD FS)?
- Single sign-on with with Office 365, for example.
- How many users and devices will your PKI support? This series is directed towards SMBs, but even still…
- Maybe you need to plan for three-tier, multi-site, or multiple Enterprise CA’s at the second or third tier.
- Will you need support for SSL certificates for internal web services?
- Do you want private key archival for the ability to recover Domain user certificates?
- Will you need to implement OCSP? Will you want to in the future?
In an effort to prevent this series from growing too large to be immediately helpful, I’m going to write it with a few common assumptions below. I know this won’t cover everybody’s situation, but I believe it is enough to get you set up and going strong. This can also serve as a brief non-exclusive outline of what I will be covering in this series.
- Certificates will need to be validated publicly, as in the S/MIME example above.
- Running with S/MIME, plus file encryption implementation first, then expanding later.
- Certificates will be distributed automatically via AutoEnrollment for local Domain users and/or devices, with the ability to distribute certificates to external users who are not on the domain, network, or who may not be local.
- The PKI will be set up in a typical SMB setting that doesn’t require three tiers, or multiple Enterprise CA’s per tier, but will leave it open as an option.
- Assuming you care about the security of your CA’s, in that the CA’s themselves will not be directly accessible publicly, and will publish to or put that off to the IIS server.
- Leave open the possibility that DA, IPsec, SSO, AD FS, and other needs may come in the future.
- Email users will include Outlook and Thunderbird users on Windows 7 to 10, OSX, iOS, and Android — how to get digital signatures and encryption working on it all.
- SSL certificates for web servers and services distribution.
- Private key archival implementation (and recovery) for AutoEnrollment domain users.
- Although some companies may have policies in place that not allow this, I will cover it anyways.
- I will not be covering OCSP immediately in this series. In a typical SMB, there are no performance benefits to using OCSP, as the CRL files will be so tiny. I will, however, add it in and link to it later.
- Newer Windows prefer OCSP over CRLs first, but regardless, I will still add it later.
- OCSP info is in certificates, so if you implement it later, it will only effect new certificates.
Here I will lay out the design, and briefly explain some how’s and why’s.
- Off-line, Off-domain Root CA
- Domain-joined Enterprise (issuing) CA
- Domain-joined IIS server
Root CA
The Off-line off-domain RootCA is turned off, and kept off, after the Enterprise CA (issuing CA) is set up. You may take it a step further and move the RootCA virtual machine off the host entirely, to some form of “in the cabinet” storage. This is done to pretty much guarantee it’s security. If the Root CA is compromised, the entire PKI; all certificates at every level, are also considered compromised. At least if a subordinate or enterprise CA is compromised, only the certificates distributed by that CA are considered compromised.
The off-line RootCA is only to be turned on in the following cases:
- If you need to renew the Root CA or Issuing CA (tier 2) certificate.
- You need to add another 2nd tier Enterprise or Subordinate CA.
- A second tier CA is compromised and you need to revoke it’s certificate.
- To renew or republish the Root CA’s CRL (certificate revocation list). Root CA’s really do not need Delta CRLs.
- You would need to renew / republish this if you haven’t changed the “CRL publication interval” of the Root CA. In that case, you would need to turn it on periodically to republish at default interval.
- To overcome this, set it to a high number such as 10 or 20 years (the same or lower than the expiration of your Enterprise CA’s certificate). If you happen to revoke a 2nd tier CA certificate in the meantime, then you can simply turn it on and republish the CRL.
- You would need to renew / republish this if you haven’t changed the “CRL publication interval” of the Root CA. In that case, you would need to turn it on periodically to republish at default interval.
Enterprise CA
The domain-joined Enterprise or Issuing CA’s job will be to only issue certificates, and to publish CRL’s and Delta CRL’s (to the IIS server) at an interval that works best for your environment. We don’t want a CA accessible from the internet, or to be responsible for certificate CRL look-ups and other web services. I like to deploy it like this to keep the CA’s safer.
IIS Server
The domain-joined IIS server will be the server providing all other services. This is where the Root CA and Enterprise CA will publish their CRLs (the CDP), where the AIA will link to, and what the CRL url will point to on all certificates (unless you will host it somewhere else). Because of this, you will want to make sure the locations are publicly accessible URLs. Even if your IIS server is not publicly accessible, you still need to use publicly routable URLs in anything you include in the certificates themselves. I will explain this better later in the series, but you can always copy the CRLs and Delta CRLs to the publicly accessible web server where the CRL and AIA urls point to on the certificates. This IIS server is also where the CertSrv service will be hosted.
Mass effect 2 dlc genesis download. Now that we have some of the more important background and information out of the way, the next step is to set up the servers.
How to Submit and Generate a Certificate Request from a Windows Server 2016 CA
In this blog post, I’ll show you How to Submit and Generate a Certificate Request from a Windows Server 2016 CA and download a new certificate.
The process of submitting a request to a Certificate Authority Is very common and many Administrators are struggling to get this process right.
Types of Certificates in Windows Server 2016
How to Install Enterprise CA on Windows Server 2016
The process of submitting and generating a new certificate is a two steps process listed below:
- Request – This is the process where we create a certificate request and save it as a.CER file, In many cases your application or you will create it from IIS or the certificates MMC.
- Issuing Generating certificate – this process follows step one, Submitting the requested file to our Certificate Authority and copying the new certificate
Step one
The first step is to generate a CSR. As we have finished installing a web server in our previous article now let’s secure the default website hosted under IIS and the certificate will be issued by a local CA in the same domain.
In order to generate CSR lets launch IIS and highlight your server name in the left pane.
Now you will have to double click on Server Certificates icon in the middle pane of IIS (see below):
Windows Server 2016 Migrate Certificate Authority
Click Create Certificate Request in the right pane.
You will see a new pop-up Distinguished Name Properties where you need to fill out all the information requested to generate a CSR.
- Common Name: The Fully Qualified Domain Name that the certificate will be issued to and secure. for example www.yourdomain.com or if you are enrolling for a wildcard certificate *.yourdomain.com
- Organization: The Registered Organisational Name the certificate belongs to.
- Organizational Unit: The Department within the Organization.
- City/locality: The Business registered location (not the actual server location).
- State/province: The Business registered state or province (Do not abbreviate).
- Country/region: The two-letter ISO country code.
After you fill all the Information and hit Next. It will show you Cryptographic Service Provider Properties wherein you leave the Cryptographic Service Provider to default Microsoft RSA Schannel Cryptographic Provider, however, change the Bit length to 2048.
Now let’s provide the path where you want to save the CSR file:
That’s it we finished with STEP 1 of generating a CSR successfully.
See how a CSR txt file looks like:
Step two
In this step, I’ll log in to my CA (Need to be a Domain Administrator to do so)
To Issue the certificate, I’ve logged In to my CA Server and I’m using the URL below (change to your hostname or access it from the CA Server ) to access the CA Admin Interface
Note: you will need to use a Domain Admin account to complete this process
In the Web, Interface click on Advanced Certificate request (Need for Web Server Certificate)
Next, Copy the request file content without white spaces
In the Certificate Issued page click on Download Certificate
-->Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016
Windows Server 2016 Certificate Authority Application
You can use this procedure to install Active Directory Certificate Services (AD CS) so that you can enroll a server certificate to servers that are running Network Policy Server (NPS), Routing and Remote Access Service (RRAS), or both.
Important
Windows Server 2016 Certificate Authority Online
- Before you install Active Directory Certificate Services, you must name the computer, configure the computer with a static IP address, and join the computer to the domain. For more information on how to accomplish these tasks, see the Windows Server 2016 Core Network Guide.
- To perform this procedure, the computer on which you are installing AD CS must be joined to a domain where Active Directory Domain Services (AD DS) is installed.
Membership in both the Enterprise Admins and the root domain's Domain Admins group is the minimum required to complete this procedure.
Note
To perform this procedure by using Windows PowerShell, open Windows PowerShell and type the following command, and then press ENTER.
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
After AD CS is installed, type the following command and press ENTER.
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA
To install Active Directory Certificate Services
Tip
If you want to use Windows PowerShell to install Active Directory Certificate Services, see Install-AdcsCertificationAuthority for cmdlets and optional parameters.
- Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group.
- In Server Manager, click Manage, and then click Add Roles and Features. The Add Roles and Features Wizard opens.
- In Before You Begin, click Next.NoteThe Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected Skip this page by default when the Add Roles and Features Wizard was run.
- In Select Installation Type, ensure that Role-Based or feature-based installation is selected, and then click Next.
- In Select destination server, ensure that Select a server from the server pool is selected. In Server Pool, ensure that the local computer is selected. Click Next.
- In Select Server Roles, in Roles, select Active Directory Certificate Services. When you are prompted to add required features, click Add Features, and then click Next.
- In Select features, click Next.
- In Active Directory Certificate Services, read the provided information, and then click Next.
- In Confirm installation selections, click Install. Do not close the wizard during the installation process. When installation is complete, click Configure Active Directory Certificate Services on the destination server. The AD CS Configuration wizard opens. Read the credentials information and, if needed, provide the credentials for an account that is a member of the Enterprise Admins group. Click Next.
- In Role Services, click Certification Authority, and then click Next.
- On the Setup Type page, verify that Enterprise CA is selected, and then click Next.
- On the Specify the type of the CA page, verify that Root CA is selected, and then click Next.
- On the Specify the type of the private key page, verify that Create a new private key is selected, and then click Next.
- On the Cryptography for CA page, keep the default settings for CSP (RSA#Microsoft Software Key Storage Provider) and hash algorithm (SHA2), and determine the best key character length for your deployment. Large key character lengths provide optimal security; however, they can impact server performance and might not be compatible with legacy applications. It is recommended that you keep the default setting of 2048. Click Next.
- On the CA Name page, keep the suggested common name for the CA or change the name according to your requirements. Ensure that you are certain the CA name is compatible with your naming conventions and purposes, because you cannot change the CA name after you have installed AD CS. Click Next.
- On the Validity Period page, in Specify the validity period, type the number and select a time value (Years, Months, Weeks, or Days). The default setting of five years is recommended. Click Next.
- On the CA Database page, in Specify the database locations, specify the folder location for the certificate database and the certificate database log. If you specify locations other than the default locations, ensure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or computers from accessing the CA database and log files. Click Next.
- In Confirmation, click Configure to apply your selections, and then click Close.
Unlock the full course today
Join today to access over 13,000 courses taught by industry experts or purchase this course individually.
Course details
Don't go to third-party certificate authorities. Active Directory Certificate Services (AD CS) allows organizations to build their own public key infrastructures (PKI) to provide certificate-based authentication, digital signatures, email encryption, and more. With AD CS, you can leverage your existing Active Directory and Group Policy settings, and set up certificates more efficiently and nimbly. Join Scott Burrell in this course, which covers planning, installing, and troubleshooting AD CS in Windows Server 2016. Learn how to create a hierarchy of certificate authorities; issue, manage, and revoke certificates; automate certificate generation and renewal; and improve login security by using certificates in combination with smart cards. These topics map to the Certificate Services domain of the Microsoft exam 70-742, so you'll also be able to use this course to prepare for MCSA certification.Skills covered in this course
Related courses
Course Transcript
- [Voiceover] I wanted to spend a little time at the close of this chapter covering some of the most common issues that you can run across with certificate servers and how to address them. For starters, the configuration of an online responder can often fail at the very last step. If, instead of the nice little working status that you see here, you may be told that you have a bad signing certificate on the array controller which would mean that something went wrong with the OCSP Certificate when you attempted to pull. Security is one of the key reasons that a certificate would not be available and we configured the security of our OCSP response signing certificate to allow any authenticated user to enroll in that certificate. But what if it's not a user that needs to enroll at all? Sometimes resolving security questions requires you to consider who or what is actually requesting the certificate. Sometimes a certificate is being requested not by a user but by a computer. And if we go…Download courses and learn on the go
Watch courses on your mobile device without an internet connection. Download courses using your iOS or Android LinkedIn Learning app.Download on the App StoreGet it on Google PlayWatch this course anytime, anywhere. Get started with a free trial today.