Windows Server 2012 R2 Two-Tier PKI CA Pt. 3

1-10-2014 6-57-56 AMNow that we have our Windows Server 2012 R2 certificate authority configured in Part 1, and our subordinate setup in Part 2, now we should setup autoenrollment and secure the subordinate’s web certificate services with SSL. Autoenrollment is where domain joined Windows computers are automatically issued a computer certificate. Services such as IIS and Microsoft SCCM can take advantage of these certificates. Finally, I’ll show you how to configure certificate delegation so authorized administrators in your organization can submit certificate requests for certain templates. This is a short series, at just three installments. But this should point you in the right direction for thinking about how to deploy your two-tier Certificate Authority on Windows Server 2012 r2.

Autoenrollment Configuration

1. Open your domain level GPO (Default Domain Policy in my case) and navigate to Public Key Policies as shown in the figure below. Double click on the highlighted policy.

1-4-2014 8-51-24 PM

2. Enable the policy and check the two options below.

1-4-2014 8-51-07 PM3. On your subordinate CA, open the CA snap-in and manage the Certificate Templates as shown below.

1-4-2014 8-54-37 PM4. Scroll down and locate Workstation Authentication. Right click and Duplicate the template.

5. Click on the General tab and enter a template name (any name). I’ll use Client-Server Authentication. I also changed the validity period to 2 years.

1-4-2014 8-58-07 PM

6. Click on the Extensions tab. Highlight Application Policies and click Edit. Add Server Authentication.

1-4-2014 9-00-46 PM

7. Click on the Security tab and modify the Domain Computers group to enable Autoenroll. Close out the template and template window.

1-4-2014 9-01-46 PM

8. Back in the issuing CA console right click on Certificate Templates, select New, then Certificate Template to Issue. Select the template name you just created. Wait a few minutes for the settings to simmer a bit. If you want you could also publish the Domain Controller template. This will enable the DCs to offer LDAPS services. If the template you just created is not listed, you can simply wait a bit or restart the CA services and that should kick it in the pants.

windows server 2012 r2 certificate authority

Autoenrollment Validation

1. Open an elevated command prompt or Powershell and type gpupdate /force. Wait a couple of minutes, as certificate enrollment is not always instant.

2. Open a blank MMC console and add the Certificates snap-in. Manage the Computer account.

1-4-2014 9-14-11 PM

3. On your subordinate CA you should now see two certificates. In my case the top certificate was the one issued by the autoenrollment policy.

1-4-2014 9-16-20 PM

4. You can verify the certificate was issued from the proper template by opening the properties then on the Details tab look for the Certificate Template Information property. It will clearly state the template name used to create the certificate.

1-4-2014 9-17-29 PM

5. As the GPO refreshes on other computers in the domain, they should also be issued a certificate as well. Autoenrollment can run into snags, so I have seen cases where everything has been configured properly but for some reason a certificate is not issued.

Configure CA Web Services for SSL

1. After the autoenrollment certificate has been validated on the subordinate CA, open the IIS Manager on your subordinate CA.

2. In the left pane select Default Web Site. In the right pane select Bindings.

3. Click on https then click Edit.

4. Select the SSL certificate that was created from the client-server template. You can view the certificate in the GUI if you aren’t sure which one to pick.

1-4-2014 9-35-37 PM

5. Open IE and navigate to the FQDN of your subordinate CA and to the certsrv site (e.g. https://D002Misc01.contoso.local/certsrv). You will likely be prompted for credentials, then presented with the standard ADCS home page. You should not have any SSL errors or warnings.

1-4-2014 9-39-32 PM

Template Delegation

1. On your subordinate CA and open the Certificate Template manager as shown below.

1-10-2014 7-26-06 AM

2. Locate the certificate template which you want to delegate. In my case I have a VMware-SSL template that I want to delegate to the group we created earlier in this series. Open the properties for the certificate template and select the Security tab. Add the Role_Issue Certificates group (or whatever your group is called) and give it the Enroll permission.

1-10-2014 7-28-14 AM

3. Optionally you configure the CA to allow requests to be submitted, but require a CA administrator to approve the certificates before they can be issued. If you want to do this, open the Issuance Requirements tab and check to the CA certificate manager approval box. This would defeat the purpose of autoenrollment certificates, such as those for computers, so generally this would be for certificates that users are requesting.

1-10-2014 7-32-51 AM

What’s Next?

If you want to issue SSL certificates for your VMware infrastructure, then you can check out my post here for the template requirements. Although that article is for vSphere 5.5, the template will also work for vSphere 4.x and 5.x. Now you have a fully functional, for lab/home usage, offline root and online subordinate CA. As I stated in Part 1, this guide just shows you the general technical steps for a two-tier Certificate Authority. There’s a lot of processes and procedures that an organization needs to flesh out and document before deploying PKI in the environment. There could be legal or other consequences if you just throw this on a production network and then down the road experience security issues which can be traced back to a poorly implemented CA.

Windows Server 2012 R2 Two-Tier PKI CA Pt. 2

1-5-2014 2-43-05 PMNow that our root Windows Server 2012 R2 certificate authority is installed and published to Active Directory from Part 1, it is time to bring online our subordinate CA. The subordinate CA will be our online issuing CA, since it will be the CA which issues all certificates, be they for users, computers, ESXi hosts, etc. The VM will be joined to the domain, and be online 100% of the time.

As with the offline root, you should perform hardening of this VM as well. Enabling the Windows firewall (or a third party one), anti-virus software, Microsoft EMET, and following Microsoft security baseline settings are all strongly recommended. If you have security software that can monitor file changes or system integrity, that too would be a great idea. Auditing tools such as Splunk, for real time alerting, would be ideal for defense in depth.

Install Windows Server 2012 R2 Subordinate CA

1. Use Notepad and create a file called CAPolicy.inf in C:\Windows on your subordinate VM. Use the code snippet below, but change the URL to match that previously used in configuring your offline root.

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://www.contoso.local/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

4. Run the following PowerShell command. Change the CACommonName as needed. The command will completely instantly.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
Add-WindowsFeature Adcs-web-enrollment
install-adcswebenrollment
Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CACommonName "IssuingCA-D002MISC01" -KeyLength 2048 -HashAlgorithm SHA256 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

5. Copy the resulting request (see the yellow information text from the last command for the path and file name) to the offline CA.

6. On the offline CA type the following command, using your filename:

certreq -submit D002MISC01.contoso.local_IssuingCA-D002MISC01.req

7. You will now see that the request is pending. Take note of the RequestId, as it will be unique to you.

1-4-2014 7-47-29 PM

8. Open the CA Manager snap-in on your offline root and issue the pending certificate.

1-4-2014 7-48-25 PM9. While still on the offline CA, enter the following command to download the new certificate. Replace “2” with your request ID, and change the filename as you see fit.

certreq -retrieve 2 c:\D002MISC01.contoso.local_IssuingCA-D002MISC01.crt

10. Copy the certificate file to the online subordinate CA. Note: Do NOT place it in the pki directory. Run the commands below to install the new certificate. Once the certificate is installed, delete the file and empty the trashcan.

Certutil –installcert a:\ D002MISC01.contoso.local_IssuingCA-D002MISC01.crt
start-service certsvc
copy c:\Windows\system32\certsrv\certenroll\*.cr* d:\pki\

Configure Subordinate CDPs

1. Next up we need to configure the proper CRLs for our subordinate CA. Enter the following commands in an elevated Powershell on your subordinate CA.

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
Add-CACRLDistributionPoint -Uri http://www.contoso.local/pki/%3%8%9.crl">http://www.contoso.local/pki/%3%8%9.crl -AddToCertificateCDP -Force
Add-CACRLDistributionPoint -Uri file://\\D002Misc01.contoso.local\pki\%3%8%9.crl" file://\\D002Misc01.contoso.local\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia http://www.contoso.local/pki/%1_%3%4.crt" http://www.contoso.local/pki/%1_%3%4.crt -Force
Certutil -setreg CA\CRLPeriodUnits 2
Certutil -setreg CA\CRLPeriod "Weeks"
Certutil -setreg CA\CRLDeltaPeriodUnits 1
Certutil -setreg CA\CRLDeltaPeriod "Days"
Certutil -setreg CA\CRLOverlapPeriodUnits 12
Certutil -setreg CA\CRLOverlapPeriod "Hours"
Certutil -setreg CA\ValidityPeriodUnits 5
Certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\AuditFilter 127
restart-service certsvc
certutil -crl

CA Delegation

1. Now that our online subordinate CA is up and running, for the most part, it is a good idea to delegate who has rights to manage the CA and issue certificates. I’m going to create two roles: One that can manage all aspects of the CA, and another that can just mint specific certificates. In AD create two groups: Role_CA Manager and Role_Issue Certificates. Or use whatever names you like.

2. On your subordinate CA, launch the CA MMC Snap-in. Right click on the CA name, open the properties, and select the Security tab, and add the Role_CA Manager group. Give it Manage CA permissions. If you want, you can remove rights from Domain Admins or Enterprise Admins, should you want to more tightly control CA access (which you should).

windows server 2012 r2 certificate authority

Summary

At this point in the configuration there are no published templates. So in the following post we will configure a couple of templates, and I’ll show you how to delegate permissions so that other administrators can mint their own certificates. In this installment we’ve done the bulk of the subordinate CA configuration. At this point the CA is now functional, although no templates have been configured. So coming up in the next installment is, among other things, the process to configure templates and computer autoenrollment. Check out Part 3 here.

Windows Server 2012 R2 Two-Tier PKI CA Pt. 1

windows server 2012 R2 certificate authorityWhile I have written a number of articles focused on SSL certificates and templates, I have not done a mini-series on how to actually install a Windows Certificate Authority. For this series I’m using Windows Server 2012 R2, but the steps are pretty much identical for Windows Server 2012. Microsoft blogs have several PKI configuration series, which directly guided the content of this series. But I always have my own spin, so I think its worthwhile to do yet anther blog post on configuring a MS CA…the “Mr. SSL” way.

Windows Server 2012 R2 Certificate Authority

The process is fairly simple: Build an offline root, create an online issuing CA, setup a couple of templates, setup auto-enrollment, then do a little post setup configuration. This requires two VMs, each running Windows Server 2012 R2 (or plain 2012 if you wish).

Building an enterprise CA is non-trivial, and should be highly process oriented. While this short series will provide the steps how to configure a two tiered hierarchy, it alone is not enterprise grade and ready for a fortune 500 company. Many operational procedures, access controls, etc. need to be defined by the organization. For example, who can issue certificates? Who can revoke them? Do users need PKI certificates or just computers? How about key recovery? Disaster recovery? Do you need a hardware security module (HSM)? Do you require FIPS compliance? What ciphers and hashing algorithms will you allow? Where do you store the offline CA?

As you can see, there are many questions and processes that need to be well documented for a solid PKI solution. However, for a lab environment where you want to test out a two-tiered model, then this short series is for you. Please don’t take this solution as-is and throw it into production. You will have a false sense of security and possibly do more harm than good.

The Microsoft CA issues industry standard certificates (x.509), and thus will work with third party hardware and software. For instance, they will work perfectly fine on the Linux vCenter appliance, or your hardware load balancers. You just need to use the proper certificate template, and verify compatible algorithms.

Offline Root CA Hardening

1. Provision a standalone Windows Server 2012 R2 server. I used vCenter 5.5 with customization specifications to create the VM. You can use the ‘standard’ edition of the OS since all SKUs in 2012 have the exact same feature set, unlike 2008 R2 and earlier. For security purposes I would not provision a NIC, or remove the NIC after you’ve built the CA to prevent future network attacks.

2. Configure a virtual floppy for the offline CA VM. This is a good way to transfer data between the offline CA and the subordinate, which is required during the configuration process. Yes you could connect a NIC, but then your offline CA is no longer offline and exposed to network attacks. Media needs to be read/write, so an ISO image will not suffice. You can use a tool like WinImage to create a floppy image.

3. Open the local security policy and modify the Audit Object Access to record Success and Failures. This is needed to audit certain CA actions, in conjunction with a CA flag we will set later on.

1-5-2014 1-18-44 PM

4. Depending on your VM template hardening, you may or may not need to modify the password policy. Again in the Local Security editor. Modify to meet your organization’s security requirements.

1-5-2014 1-23-08 PM

5. You should also rename the Administrator account, if that’s not already built into your templates. Make sure to record the new name, or you could be in a pickle. For good measure I’d rename the guest account, although it should be disabled.

1-5-2014 1-25-28 PM

6. Obviously you should change the administrator password and not use your template default. Be sure to record the password in a secure location.

7. You should also think about where you will store the offline CA VM once it is build and this project is complete. If you leave it sitting on a production ESXi host, then it would be fairly trivial to power on the VM and compromise it. I would not call storing your “offline” CA in a powered off state on a production ESXi host “offline”. I would look at exporting the VM to an OVF file, then storing that file on removable media in a very secure location. You could use a DVD, Blu-Ray, or USB stick.

Install Offline Root CA

1. After your VM is provisioned and hardened, make sure the computer name is configured. In my case the offline CA is name D002CA01. Reboot if you changed the name.

2. Use Notepad and create a file called CAPolicy.inf in C:\Windows. Use the code snippet below, but change the URL. This URL is where your Certification Practice Statement (CPS) is located. It will also be where the CRL (certificate revocation list) will be published. For a production deployment you’d want to create a CPS, but for this exercise we will skip it, however the URL will be configured for future usage. For additional details see this TechNet link. You probably want to use a different URL like CA.yourdomain or PKI.yourdomain since we will be publishing other data to this address such as the CRL. For simplicity I stuck with www.contoso.local. Make sure the filename does not have any extra extensions like .txt. Verify from the command line.

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://www.contoso.local/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

3. Run the following PowerShell command. Change the CACommonName as needed. The command will complete instantly. I would make it clear in the name that this is the Root CA. This name will be present in all issued certificates, so make it obvious what it is and not just some generic hostname that is not meaningful. Notice that we are using SHA256 here, since SHA1 is no longer considered secure. You could also use SHA512.


Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority –CAType StandaloneRootCA –CACommonName "ContosoRootCA" –KeyLength 2048 –HashAlgorithm SHA256 –CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

1-4-2014 2-05-36 PM

4. Run the following commands, using the appropriate URL for your organization. We aren’t using HTTPS here, because that requires SSL and certificate validation. This is just used to download the CPS and CRLs, so don’t get clever and use HTTPS here. We will configure SSL for the web enrollment module, though.


$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8.crl -PublishToServer -Force
Add-CACRLDistributionPoint -Uri http://www.contoso.local/pki/%3%8.crl -AddToCertificateCDP -Force
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Certutil -setreg CA\CRLOverlapPeriodUnits 12
Certutil -setreg CA\CRLOverlapPeriod "Hours"
Certutil -setreg CA\ValidityPeriodUnits 10
Certutil -setreg CA\ValidityPeriod "Years"
Certutil -setreg CA\AuditFilter 127
restart-service certsvc
certutil -crl

5. Verify that two and only two CRL distribution points are configured.

Get-CACRLDistributionPoint | format-list

1-4-2014 3-12-39 PM6. Navigate to C:\Windows\System32\CertSrv\CertEnroll. You should see two files, one ending in CRL and another ending in .CRT. These two files need to be copied to what will be the online subordinate CA.

1-4-2014 4-17-37 PM

Publish Root CA to the Forest

1. Provision a Windows Server 2012 R2 VM which will be your online CA. Join it to the domain. In my case the VM is named D002MISC01. Do not try and be clever and use a Domain Controller. The server will later need IIS installed and access to local accounts, which is not possible on a DC. So use a member server for your online CA, even in a home lab.

2. Login to what will be your online subordinate CA with an account that is a member of both Domain Admins and Enterprise Admins. Mount the media which has the two files copied from your offline CA. Open an elevated Powershell and enter the following commands, using the file names for your instance. This will publish the offline root CA information to AD, just as if it were an online CA. By doing this all domain joined clients will automatically trust your root CA. If you have standalone computers, then you can import the .crt file into their trusted certificate store.

certutil –dspublish –f D002CA01_ContosoRootCA.crt RootCA
certutil –addstore –f root D002CA01_ContosoRootCA.crt
certutil –addstore –f root ContosoRootCA.crl

1-4-2014 4-19-11 PM

CPS and CRL Distribution

1. Now you need create a DNS record for the host that will be publishing your online CA information. In this case it’s D002MISC01, and per my previous steps I stuck with ‘www’ as the site name. I’m assuming the proper DNS zone already exists, since you have a domain with Active Directory up and running. This must be configured prior to continuing, as the subordinate will fail to properly configure if the CRL file is not available.

1-4-2014 4-25-31 PM

2. We need to install IIS, since we will be distributing the CPS and CRL via the HTTP. On the VM which will be your online CA, run the following command:

Install-WindowsFeature Web-WebServer -IncludeManagementTools

3. Open an elevated PowerShell and enter the following commands. If you have an official CPS, then you can skip the second command and just copy your cps.txt file to the directory. For security purposes I’d recommend putting the files on the D: drive, so you aren’t serving content from the OS drive.

new-item -path D:\pki -type directory
write-output "This is a sample CPS. Modify as needed." | out-file D:\pki\cps.txt
new-smbshare -name pki D:\pki -FullAccess SYSTEM,"Contoso\Domain Admins" -ChangeAccess "Contoso\Cert Publishers"

4. Open the IIS Manager and add a Virtual Directory as shown below.

1-4-2014 7-19-27 PM

1-4-2014 7-20-39 PM

5. Verify pki is selected in the left pane, then single click Authentication in the middle pane, and in the right Actions pane click on Edit Permissions.

6. Select the Security tab and select Edit. Add the Cert Publishers group with Modify permissions (which will add several others under it).

1-4-2014 7-10-14 PM

7. In the same dialog box, click add but change the from this location to the local computer. Manually enter IIS AppPool\DefaultAppPool. Leave the default permissions. If you use the user/group browser this will not be listed, so please manually enter it.

8. At this point any anonymous browser can now read your CPS statement and see the public root certificate. You can test this by going to http://www.yourdomain/pki/cps.txt and verify the sample file opens.

9. In the middle pane, with pki still selected, click once on Request Filtering. In the right pane click on Edit Feature Settings and check the box next to Allow double escaping.

1-4-2014 7-12-45 PM

10. Run iisreset from an elevated Powershell command.

Summary

In this installment we’ve configured our offline root CA, performed some hardening, and published the root CA information to the domain. All computers in the domain will now trust your root CA. We also configured IIS to serve up your CPS and CRLs to anonymous users. Next up is configuring the online subordinate CA. Check out the next installment in Part 2.

vSphere 5.5 Install Pt. 9: Offline SSL Minting

10-4-2013 6-19-17 PMNot everyone has an online Microsoft Certificate Authority, or maybe my toolkit script has issues in your environment. So in this installment we will go over manual SSL minting. By that I mean we will use my Toolkit script to create the CSRs, you will download the certificates yourself, then run my Toolkit script again to create all of the required files. So in reality the only manual process is getting the certificate.

Even if you don’t have an online Microsoft CA, I suggest reading through Part 8. It will familiarize you with my vCenter 5.5 Toolkit script and has the change log. If have an online Microsoft CA and ran the script in the previous post then you can skip this installment and go to Part 10 (coming soon).

Blog Series

SQL 2012 AlwaysOn Failover Cluster for vCenter
vSphere 5.5 Install Pt. 1: Introduction 
vSphere 5.5 Install Pt. 2: SSO 5.5 Reborn 

vSphere 5.5 Install Pt. 3: vCenter Upgrade Best Practices and Tips
vSphere 5.5 Install Pt. 4: ESXi 5.5 Upgrade Best Practices and Tips 
vSphere 5.5 Install Pt. 5: SSL Deep Dive
vSphere 5.5 Install Pt. 6: SSL Certificate Template
vSphere 5.5 Install Pt. 7: Install SSO
vSphere 5.5 Install Pt. 8: Online SSL Minting
vSphere 5.5 Install Pt. 9: Offline SSL Minting
vSphere 5.5 Install Pt. 10: Replace SSO Certificates
vSphere 5.5 Install Pt. 11: Install Web Client 
vSphere 5.5 Install Pt. 12: Configure SSO
vSphere 5.5 Install Pt. 13: Install Inventory Service
vSphere 5.5 Install Pt. 14: Create Databases
vSphere 5.5 Install Pt. 15: Install vCenter
vSphere 5.5 Install Pt. 16: vCenter SSL
vSphere 5.5 Install Pt. 17: Install VUM
vSphere 5.5 Install Pt. 18: VUM SSL
vSphere 5.5 Install Pt. 19: ESXi SSL Certificate

Permalink to this series: vexpert.me/Derek55
Permalink to the Toolkit script: vexpert.me/toolkit55

Offline SSL Method

1. Download my vCenter 5.5 toolkit script from the link above. Open it in the PowerShell ISE (or favorite editor). The PowerShell script requires a few variable modifications before you run it. In the first block of variables you need to setup the directory where you want all of the certificates to go. If OpenSSL is already installed, change the path so the script knows where the root directory is. If that directory does not exist OpenSSL will be downloaded and installed for you. Next up are the certificate properties. Change those to suite your environment. If you want the server’s IP address in the SAN field, then uncomment the line and change the IP.

10-10-2013 7-04-44 PM

2. Execute the PowerShell Toolkit script. Unlike part 8 where we selected option 1 and everything was automated, here we need to select the option behind door number 2. This will create all of the required directories, private RSA keys and CSRs for you.

10-9-2013 4-52-21 PM

2. The first screenshot are the seven service directories which get automatically created. Inside each directory are three files. In the second screenshot the rui.key file is your private 2048 bit RSA key. The .cfg file is the OpenSSL configuration file that was used to generate the CSR. The .csr file is what you will submit to your CA.

10-4-2013 6-51-01 PM

10-4-2013 6-44-06 PM

3. Now you need to take each of the seven CSR files and submit it to your CA. In case you have an offline Microsoft CA or there are strong security measures in place so the vCenter can’t access your CA directly, I’ll cover the manual issuing and downloading process with a Microsoft Windows Server 2012 CA. If you have a non-Microsoft CA, then just skim over the Microsoft CA section, save your certificates as rui.crt in each directory, and pick back up at step 8.

4. Go to the URL of your Microsoft CA. The default address is https://hostname/certsrv. Make sure you are accessing the CA page with credentials that can request VMware-SSL certificates. Click on Request a certificate.

10-4-2013 7-00-57 PM

5. Select the second option, Submit a certificate request by using a base-64-encoded….

10-4-2013 7-03-33 PM

6. Copy and paste the CSR information from the first service into the top pane. Make sure the VMware-SSL template is selected. If that template is NOT listed then you probably goofed up one of three things 1) You accessing the CA web site with your non-admin account 2) You didn’t properly publish the VMware-SSL certificate template 3) You don’t have enroll permissions on the VMware-SSL template. Do not enter any additional attributes.

10-4-2013 7-05-27 PM

7. After you submit the certificate request you need to download the Base-64 encoded version WITHOUT the certificate chain. Name the file rui.crt and save it back into the same service directory that you submitted the CSR from. These certificates are NOT interchangeable, so don’t get the rui.crt files mixed up. The system will barf later on and you will lose some hair. Each certificate must match the service it was intended for.

10-4-2013 7-09-29 PM

8. After you’ve done this for all seven certificates, each service directory should now look like the following, with a rui.crt file now present.

10-4-2013 7-15-23 PM

9. Next up we need to create one or two root CA files, depending on your CA architecture. Double click on one of your .crt files and go to the Certification Path tab. In my example below we have two CAs: A root and a subordinate. The CA at the top is the root and the next one down is the subordinate. vCenter needs the public certificate from both, so that it can properly chain.

10-4-2013 7-17-20 PM

10. If you are using a Microsoft CA then go back to the Home page of the CA. But this time select the last option, Download a CA certificate…

10-4-2013 7-22-02 PM

11. Click on Download CA certificate chain if you have a Root/subordinate CA architecture. If you have just a root CA click on Download CA Certificate. If you are downloading the chain, just save it to your desktop with any ole name and skip to step 12. If you have just a root CA, then save the file as Root64.cer in the root of your certificate directory (screenshot below).

10-4-2013 7-23-33 PM

Root only CA:

10-4-2013 7-40-48 PM

12. For those that downloaded their chain (and ball), double click the certificate and locate the two certificates. Right click on your ROOT (see step 9), select All Tasks, and Export. Save the certificate as a Base-64 encoded file and name it Root64.cer. Put it in the root of your certificate directory as show in step 11.

10-4-2013 7-37-28 PM

13. Repeat the process on the subordinate CA, but save the file as interm64.cer. You should now have a directory that looks like:

10-4-2013 7-47-04 PM

13.  Re-run the Toolkit script but now we select Option 3. This will process all of the files and create the exact same output as the online option in Part 8. Review the screen events for any errors.

10-10-2013 7-31-55 PM

A sample of the screen output is below.

10-10-2013 8-12-40 PM

Output Validation

1. Assuming no errors occur, you should now see additional files in the root of your certificate directory. A chain.cer file should now appear if you have an intermediate CA. A hash file (which ends in 0) for each root certificate will also be listed.  If you only have a root CA then you will have one hash file.

10-9-2013 5-05-54 PM

2. If you take a peek inside one of the folders you will see a series of files. Each service, except SSO, will have the same set of files (except the .csr and .cfg with are uniquely named). The

  • chain.pem: Used for the VMware vCenter certificate automation tool
  • rui.crt: Public half of your SSL certificate
  • rui.key: Private half of your SSL certificate
  • rui.pfx: Combined private and public SSL keys
  • *.cfg:  Certificate signing request file
  • *.csr: Certificate signing request

10-9-2013 5-09-43 PM

3. In the vCenterSSO you will see a plethora of files. Depending on how you replace your SSL certificates, you may only use some of these files. But to help you out as much as possible, all the SSO files that are tedious to create manually are created for you. If you are missing files, then something went wrong. Please match up all filenames to validate the toolkit script worked. Some files are copies of each other, but they are needed to avoid confusion and more easily follow the KBs.

  • *.properties: Use for manual SSO SSL replacement
  • *_id: Use for manual SSO SSL replacement
  • ca_certificates.crt: Use for manual SSO SSL replacement
  • root-trust.jks: Used for SSO/STS certificate validation
  • server-identity.jks: Same file as above with a different name (per VMware KBs)
  • ssoserver.p12: Same functionality as rui.pfx, but VMware changed the name and format for SSO 5.5
  • ssoserver.crt: Copy of chain.pem
  • ssoserver.key: Copy of rui.key

10-9-2013 10-06-14 PM

Certificate Validation

Now that your certificates are minted, let’s quickly validate all of the properties are present. Even if your CSR requests a property, that doesn’t mean your CA will honor it. The OU in each subject name should be unique and match the directory it’s in.

10-10-2013 7-17-04 PM

The Subject Alternative Name should contain the short name and FQDN. Optionally it can contain your IP address too.

10-10-2013 7-18-18 PM

Enhanced key usage should show server and client authentication. Client authentication can be missing if the CA template is wrong.

10-10-2013 7-18-59 PM

Key usage should contain digital signature, key encipherment and data encipherment.

10-10-2013 7-19-43 PM

Summary

After a bit more work than the automated method, you now have all of the required certificate files to either use the vCenter certificate automation tool, or try the complex manual replacement method. Next up in Part 10 we update the SSO service SSL certificates.

vSphere 5.5 Install Pt. 6: Certificate Template

10-5-2013 3-51-55 PMNow that you understand what type of SSL certificates you need and how many vCenter 5.5 requires, we need to create a Certificate Authority template that will mint proper certificates. You may very well be able to get away with the Microsoft “Web server” template, but it is missing a few properties that VMware still lists as a requirement. So to ensure you don’t run into any problems, this installment shows you how to setup those properties.

I’m assuming you are using a Microsoft CA for this exercise. Technically you can use any CA, so don’t think that you are just limited to Microsoft’s implementation. Certificates are standardized in the X.509 format. In a real enterprise environment CAs should be heavily locked down and you probably won’t have permissions to change anything on the CA. Find your CA administrator and have them complete this section. If you aren’t using a Microsoft CA, then the steps below won’t exactly apply to you. But research how to configure your CA for the “required” properties.

Blog Series

SQL 2012 AlwaysOn Failover Cluster for vCenter
vSphere 5.5 Install Pt. 1: Introduction
vSphere 5.5 Install Pt. 2: SSO 5.5 Reborn 
vSphere 5.5 Install Pt. 3: vCenter Upgrade Best Practices and Tips
vSphere 5.5 Install Pt. 4: ESXi 5.5 Upgrade Best Practices and Tips
vSphere 5.5 Install Pt. 5: SSL Deep Dive
vSphere 5.5 Install Pt. 6: SSL Certificate Template
vSphere 5.5 Install Pt. 7: Install SSO
vSphere 5.5 Install Pt. 8: Online SSL Minting
vSphere 5.5 Install Pt. 9: Offline SSL Minting
vSphere 5.5 Install Pt. 10: Update SSO Certificate
vSphere 5.5 Install Pt. 11: Install Web Client 
vSphere 5.5 Install Pt. 12: Configure SSO
vSphere 5.5 Install Pt. 13: Install Inventory Service
vSphere 5.5 Install Pt. 14: Create Databases
vSphere 5.5 Install Pt. 15: Install vCenter
vSphere 5.5 Install Pt. 16: vCenter SSL
vSphere 5.5 Install Pt. 17: Install VUM
vSphere 5.5 Install Pt. 18: VUM SSL
vSphere 5.5 Install Pt. 19: ESXi SSL Certificate

Permalink to this series: vexpert.me/Derek55
Permalink to the Toolkit script: vexpert.me/toolkit55

Certificate Template

1. Logon to your Microsoft root CA. In this case I’m using Windows Server 2012. Launch the Certification Authority console. I’ve already created a custom template, VMware-SSL. But ignore that for now (just like a cooking show I have my template already done in the oven) and locate the Certificate Template container. Right click and select Manage.

10-2-2013 7-17-46 PM

2. Locate the Web Server template, right click and duplicate it.

10-2-2013 7-19-36 PM

3. Don’t change anything on the compatibility tab. Don’t think you are clever and try changing the default value to something like Windows Server 2012. #Fail. On the General tab rename the template. I like using VMware-SSL because it has no spaces, so the template name and display name are the same. This avoids confusion down the road where a script requires the template name as a parameter. Spaces are allowed, but let’s not confuse the situation anymore than needed…we are already confused enough.

10-2-2013 7-22-52 PM

4. Click on the Extensions tab then highlight Application Policies. Click Edit and add Client Authentication.

10-2-2013 7-26-23 PM

5. Click on Key Usage and check the box to allow encryption of user data. Close out of all the certificate properties windows.

10-2-2013 7-28-40 PM

6. Back in the CA window issue the new VMware-SSL template, by selecting the menu item shown below. A list of available templates will appear, and just click on VMware-SSL. It should now appear in the right pane, as you can see below. Sometimes CAs can be slow, and it could take a couple of minutes to appear. Do not panic; be patient. Once it appears you now have a good template to use for VMware certificates (vCenter, ESXi hosts, etc.).

10-2-2013 7-31-03 PM

Summary

Creating a certificate template is not tricky and only takes a couple of minutes. It may take a few minutes for the new certificate type to replicate in AD. So don’t be too surprised if you can’t immediately see it. The steps are pretty much the same on Windows Server 2008 and later, so don’t worry if you aren’t yet using Windows Server 2012.

In Part 7 we (finally) get to mount the vCenter 5.5 ISO and install the SSO service. So yes, this install series is finally getting to the point were we can install something. But hopefully you are better educated about vCenter 5.5 than you were before you stumbled on this series. Impress your friends at your next cocktail party about SSL OU values and PEM files.

© 2017 - Sitemap