Tag Archive: PKI


Certutil view restrict description:

http://blogs.technet.com/b/pki/archive/2008/10/03/disposition-values-for-certutil-view-restrict-and-some-creative-samples.aspx

Disposition values for requests in the queue:

Disposition Description
8 request is being processed
9 request is taken under submission
12 certificate is an archived foreign certificate
15 certificate is a CA certificate
16 parent CA certificates of the CA certificate
17 certificate is a key recovery agent certificate

Disposition values for requests in the log:

Disposition Description
20 certificate was issued
21 certificate is revoked
30 certificate request failed
31 certificate request is denied

use the sign “=”

 

Export list of issued certificates from a CA:

certutil -view -restrict “Certificate Template=TempNameOrOID” -out “requestername,requestid” | find “Requester Name:” | sort >output.csv

certutil -view -restrict “notbefore=>1/1/2015” -out “RequestID,NotBefore,NotAfter,CertificateTemplate”

Export list of issued certificates from a specific user:

certutil -view -restrict “Disposition=20,RequesterName=domain\user1” -out “RequestID,RequesterName,CommonName,NotBefore,NotAfter”

 

Show the SerialNumber of all issued and revoked certificates:

certutil -view -restrict “Disposition=20,Disposition=21” -out SerialNumber

Show all certificate requests that failed for the certificate template with the common name “EnrollmentAgent” after September 24th 2008:

certutil -view -restrict “Disposition=30,notbefore=>9/24/2008,certificate template=EnrollmentAgent” -out RawCertificate

Advertisements

Web references:

http://www.networksteve.com/forum/topic.php/CCertRequest::Submit:_The_RPC_server_is_unavailable._0x800706ba/?TopicId=54320&Posts=3

http://blogs.technet.com/b/askds/archive/2007/11/06/how-to-troubleshoot-certificate-enrollment-in-the-mmc-certificate-snap-in.aspx

https://social.technet.microsoft.com/Forums/windowsserver/en-US/f3de8600-cf4e-4a39-a42e-7f929e1b8d6d/certificate-enrollment-the-rpc-server-is-unavailable

http://blogs.msdn.com/b/windowsvistanow/archive/2008/04/08/troubleshooting-certificate-enrollment.aspx

 

Symptoms:

Trying to enroll a webserver cert (or a computer cert or user cert) gets the error The RPC server is unavailable. This CA has also issued certs in the past for computers and webservers.

certutil -ping -config server.domain.com\domain-server-ca
Connecting to server.domain.com\domain-server-ca

Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722)

CertUtil: -ping command FAILED: 0x800706ba (WIN32: 1722)
CertUtil: The RPC server is unavailable.

The same command from a command prompt on the same computer run as domain admin:

Server “domain-server-CA” ICertRequest2 interface is alive
CertUtil: -ping command completed successfully.

Solution:

Please ensure that “Authenticated Users” group is in the “Certificate Service DCOM Access” group.

Please verify that the Builtin\Users group includes the following member groups:

Authenticated Users
Domain Users
INTERACTIVE
Check the DCOM Access Limit of “My Computer” on the server encountering the issue:

1)    On the server, run dcomcnfg.exe.

2)    On the Component Services console, navigate to Component Services\Computers\My Computer.

3)    Right-click My Computer, select Properties, verify that Enable Distributed COM on this computer is selected in the Default Properties tab.

4)    Click the COM Security tab, Click Edit Limits in the Access Permission section and ensure that Everyone and Certificate Service DCOM Access has Local Access and Remote Access permissions.

5)    Click Edit Limits in the Launch and Activation Permission section and ensure that Certificate Service DCOM Access group has Local Activation and Remote Activation permissions.

6)    Click OK.

 

Is it possible to cohabit with an old PKI hierarchy and a new PKI in a same Forest?

“Yes you can have multiple root CAs and even multiple PKIs in a single Active Directory forest. Because of the way the objects are representing those CAs are named and stored, you couldn’t possibly experience a conflict unless you tried to give more than one CA the same CA name.”

http://blogs.technet.com/b/askds/archive/2010/08/23/moving-your-organization-from-a-single-microsoft-ca-to-a-microsoft-recommended-pki.aspx

Tasks to do before to remove the old CA:

“The first thing you’ll want to do is prevent the old CA from issuing any new certificates. You just uninstall it, of course, but that could cause considerable problems. What do you think would happen if that CA’s published CRL expired and it wasn’t around to publish a new one? Depending on the application using those certificates, they’d all fail to validate and become useless. Wireless clients would fail to connect, smart card users would fail to authenticate, and all sorts of other bad things would occur. The goal is to prevent any career limiting outages so you shouldn’t just uninstall that CA.”

“No, you should instead remove all the templates from the Certificate Templates folder using the Certification Authority MMC snap-in on the old CA. If an Enterprise CA isn’t configured with any templates it can’t issue any new certificates. On the other hand, it is still quite capable of refreshing its CRL, and this is exactly the behavior you want. Conversely, you’ll want to add those same templates you removed from the Old And Busted CA into the Certificate Templates folder on the New Hotness Issuing CA.

If you modify the contents of the Certificate Templates folder for a particular CA, that CA’s pKIEnrollmentService object must be updated in Active Directory. That means that you will have some latency as the changes replicate amongst your domain controllers. It is possible that some user in an outlying site will attempt to enroll for a certificate against the Old And Busted CA and that request will fail because the Old And Busted CA knows immediately that it should not issue any certificates. Given time, though, that error condition will fade as all domain controllers get the new changes. If you’re extremely sensitive to that kind of failure, however, then just add your templates to the New Hotness Issuing CA first, wait a day (or whatever your end-to-end replication latency is) and then remove those templates from the Old And Busted CA. In the long run, it won’t matter if the Old And Busted CA issues a few last minute certificates.

At this point all certificate requests within your organization will be processed by the New Hotness Issuing CA, but what about all those certificates issued by the Old And Busted CA that are still in use? Do you have to manually go to each user and computer and request new certificates? Well…it depends on how the certificates were originally requested”.

Manually Requested

If a certificate has been manually requested then, yes, in all likelihood you’ll need to manually update those certificates. I’m referring here to those certificates requested using the Certificates MMC snap-in, or through the Web Enrollment Pages. Unfortunately, there’s no automatic management for certificates requested manually. In reality, though, refreshing these certificates probably means changing some application or service so it knows to use the new certificate. I refer here specifically to Server Authentication certificates in IIS, OCS, SCCM, etc. Not only do you need to change the certificate, but you also need to reconfigure the application so it will use the new certificate. Given this situation, it makes sense to make your necessary changes gradually. Presumably, there is already a procedure in place for updating the certificates used by these applications I mentioned, among others I didn’t, as the current certificates expire. As time passes and each of these older, expiring certificates are replaced by new certificates issued by the new CA, you will gradually wean your organization off of the Old And Busted CA and onto the New Hotness Issuing CA. Once that is complete you can safely decommission the old CA.

And it isn’t as though you don’t have a deadline. As soon as the Old And Busted CA certificate itself has expired you’ll know that any certificate ever issued by that CA has also expired. The Microsoft CA enforces such validity period nesting of certificates. Hopefully, though, that means that all those certificates have already been replaced, and you can finally decommission the old CA.

Automatically Enrolled

Certificate Autoenrollment was introduced in Windows XP, and it allows the administrator to assign certificates based on a particular template to any number of forest users or computers. Triggered by the application of Group Policy, this component can enroll for certificates and renew them when they get old. Using Autoenrollment, once can easily deploy thousands of certificates very, very quickly. Surely, then, there must be an automated way to replace all those certificates issued by the previous CA?

As a matter of fact, there is.

As described above, the new PKI is up and ready to start issuing digital certificates. The old CA is still up and running, but all the templates have been removed from the Certificate Templates folder so it is no longer issuing any certificates. But you still have literally thousands of automatically enrolled certificates outstanding that need to be replaced. What do you do?

In the Certificates Templates MMC snap-in, you’ll see a list of all the templates available in your enterprise. To force all holders of a particular certificate to automatically enroll for a replacement, all you need to do is right-click on the template and select Reenroll All Certificate Holders from the context menu.

clip_image002

What this actually does is increment the major version number of the certificate template in question. This change is detected by the Autoenrollment component on each Windows workstation and server prompting them to enroll for the updated template, replacing any certificate they may already have. Automatically enrolled user certificates are updated in the exact same fashion.

Now, how long it takes for each certificate holder to actually finish enrolling will depend how many there are and how they connect to the network. For workstations that are connected directly to the network, user and computer certificates will be updated at the next Autoenrollment pulse.

Note: For computers, the autoenrollment pulse fires at computer startup and every eight hours thereafter. For users, the autoenrollment pulse fires at user logon and every eight hours thereafter. You can manually trigger an autoenrollment pulse by running certutil -pulse from the command line. Certutil.exe is installed with the Windows Server 2003 Administrative Tools Pack on Windows XP, but it is installed by default on the other currently supported versions of Windows.

For computers that only connect by VPN it may take longer for certificates to be updated. Unfortunately, there is no blinking light that says all the certificate holders have been reenrolled, so monitoring progress can be difficult. There are ways it could be done — monitoring the certificates issued by the CA, using a script to check workstations and servers and verify that the certificates are issued from the new CA, etc. — but they require some brain and brow work from the Administrator.

There is one requirement for this reenrollment strategy to work. In the group policy setting where you enable Autoenrollment, you must have the following option selected: Update certificates that use certificate templates.

clip_image003

If this policy option is not enabled then your autoenrolled certificates will not be automatically refreshed.

Remember, there are two autoenrollment policies — one for the User Configuration and one for the Computer Configuration. This option must be selected in both locations in order to allow the Administrator to force both computers and users to reenroll for an updated template.

But I Have to Get Rid of the Old CA!

As I’ve said earlier, once you’ve configured the Old And Busted CA so that it will no longer issue certificates you shouldn’t need to touch it again until all the certificates issued by that CA have expired. As long as the CA continues to publish a revocation list, all the certificates issued by that CA will remain valid until they can be replaced. But what if you want to decommission the Old And Busted CA immediately? How could make sure that your outstanding certificates would remain viable until you can replace them with new certificates? Well, there is a way.

All X.509 digital certificates have a validity period, a defined interval time with fixed start and end dates between which the certificate is considered valid unless it has been revoked. Once the certificate is expired there is no need to check with a certificate revocation list (CRL) — the certificate is invalid regardless of its revocation status. Revocation lists also have a validity period during which time it is considered an authoritative list of revoked certificates. Once the CRL has expired it can no longer be used to check for revocation status; a client must retrieve a new CRL.

You can use this to your advantage by extending the validity period of the Old And Busted CA’s CRL in the CA configuration to match (or exceed) the remaining lifetime of the CA certificate. For example, if the Old And Busted CA’s certificate will be valid for the next 4 years, 3 months, and 10 days, then you can set the publication interval for the CA’s CRL to 5 years and immediately publish it. The newly published CRL will remain valid for the next five years, and as long as you leave that CRL published in the defined CRL distribution points — Active Directory and/or HTTP — clients will continue to use it for checking revocation status. You no longer need the actual CA itself so you can uninstall it.

One drawback to this, however, is that you won’t be able to easily add any certificates to the revocation list. If you need to revoke a certificate after you’ve decommissioned the CA, then you’ll need to use the command line utility certutil.exe.

Certutil.exe -resign “Old And Busted CA.crl” +<serialNumber>

Of course, this requires that you keep the private keys associated with the CA, so you’d better back up the CA’s keys before you uninstall the role.”

Reference: http://blogs.technet.com/b/askpfeplat/archive/2013/04/22/choosing-a-hash-and-encryption-algorithm-for-a-new-pki.aspx

” If you absolutely must support legacy applications that don’t understand CNG algorithms, and are building out a new public key infrastructure, my advice today is to build two hierarchies. The first hierarchy – a legacy hierarchy if you will – would have a lower key lifetime aimed at a documented point at which legacy applications and devices MUST support CNG algorithms. You could issue certificates based on this “lower assurance” hierarchy for a limited time only to legacy clients, perhaps with limited EKUs and a specific Certificate Policy attached to it. The second PKI would be erected with more current algorithms and key lengths to support more current clients and with much longer expiry periods. When building that PKI, you could follow the stronger guidance put forth in the Federal CP and choose SHA-256, or SHA-384 along with RSA Keys of 4096 bits or ECC keys of 256 or 384 bits. I agree that this adds complexity, but I find in the IT industry that we’re constantly dragging older applications and devices into a new security world – often, kicking and screaming the entire way.”

Here are resources and comments about ADCS migration to 2012 R2:

https://windorks.wordpress.com/2014/08/12/migrating-a-microsoft-pki/

http://blog.datacenterfromhell.net/2014/12/migrating-two-tier-microsoft-pki-from.html

Is it possible to cohabit with an old PKI hierarchy and a new PKI in a same Forest?

“Yes you can have multiple root CAs and even multiple PKIs in a single Active Directory forest. Because of the way the objects are representing those CAs are named and stored, you couldn’t possibly experience a conflict unless you tried to give more than one CA the same CA name.”

http://blogs.technet.com/b/askds/archive/2010/08/23/moving-your-organization-from-a-single-microsoft-ca-to-a-microsoft-recommended-pki.aspx

Why? USE CASE: the old 2008 R2 AD CS SHA1 hierarchy and the new SHA256 hierarchy running AD CS 2012 R2

Multiple PKI Hierarchies in the Same Environment:

http://www.postseek.com/meta/fe2eee95f5a00bd80ab13f9627e2813b

 

Step by Step AD CS 2012 R2 two-tier PKI build:

http://www.flexecom.com/deploying-enterprise-pki-on-windows-server-2012-r2/

CAPolicy.inf syntax: http://blogs.technet.com/b/askds/archive/2009/10/15/windows-server-2008-r2-capolicy-inf-syntax.aspx

http://blogs.technet.com/b/askds/archive/2009/09/01/designing-and-implementing-a-pki-part-i-design-and-planning.aspx

http://davidmtechblog.blogspot.fr/2015/02/pki-public-key-infrastructure-with.html

http://kazmierczak.eu/itblog/2012/08/22/the-dos-and-donts-of-pki-microsoft-adcs/

 

http://pleasework.robbievance.net/howto-install-a-2-tier-windows-2012-r2-ad-integrated-pki-infrastructure/

 

http://www.derekseaman.com/2014/01/windows-server-2012-r2-two-tier-pki-ca-pt-1.html

http://www.derekseaman.com/2014/01/windows-server-2012-r2-two-tier-pki-ca-pt-2.html

http://www.derekseaman.com/2014/01/windows-server-2012-r2-two-tier-pki-ca-pt-3.html

 

http://hanygeorge.com/blog/2-tier-pki-on-windows-server-2012step-by-step-guide/

 

Here are list of other web resources about AD CS:

2013: Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy : http://technet.microsoft.com/en-us/library/hh831348.aspx

AD CS 2008 R2 Installation Getting Started Guide: http://technet.microsoft.com/en-us/library/cc753802(WS.10).aspx

Downloadable, printable job aids which include the most commonly used commands and procedures for administering Server Core installations are available at http://go.microsoft.com/fwlink/?LinkId=151984.

Steps for installing a server role on a Server Core installation of Windows Server 2008 R2:

Unlike Windows Server 2008, Server Core installations of Windows Server 2008 R2 use Dism.exe to install and uninstall most server roles. For more information about Dism.exe, see http://technet.microsoft.com/en-us/library/dd772580(WS.10).aspx.

Installing Windows Features on a server running a Server Core installation of Windows Server 2008 R2: http://technet.microsoft.com/en-us/library/ee441253(WS.10).aspx

Installing AD CS on a Server Core installation of Windows Server 2008 R2: By using PowerShell script: Setup Certification Authority with PowerShell

How to request and install a certificate on a server core: http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/97d388e8-eb88-4744-b47a-938065849deb/

AD CS and PKI Step-by-Steps, Labs, Walkthroughs, HowTo, and Examples:

http://www.microsoft.com/download/en/details.aspx?id=22838

AD CS 2008 step by step: http://technet.microsoft.com/en-us/library/cc772393(WS.10).aspx

http://social.technet.microsoft.com/wiki/contents/articles/4797.aspx

AD PKI 2003 step by step: http://technet.microsoft.com/en-us/library/cc772670(WS.10).aspx

How to configure Certificate based authentication for OWA: http://msexchangeteam.com/archive/2008/10/07/449942.aspx

=> Example Step by Step: http://www.corelan.be/index.php/2008/07/14/windows-2008-pki-certificate-authority-ad-cs-basics/

Checklist: Configuring certificate Auto-Enrollment:

=> http://technet.microsoft.com/en-us/library/cc773385(WS.10).aspx

Checklist: Decommissioning a certification authority

=> http://technet.microsoft.com/en-us/library/cc786938(WS.10).aspx

Troubleshooting: http://technet.microsoft.com/en-us/library/cc758774(WS.10).aspx

ADCS Certificate Templates, how to, best practices and troubleshooting:

http://www.microsoft.com/download/en/details.aspx?id=7429

http://technet.microsoft.com/en-us/library/cc758496(WS.10).aspx

Certificate Services How To… http://technet.microsoft.com/en-us/library/cc737760(WS.10).aspx

French technet articles: http://technet.microsoft.com/fr-fr/library/cc770357(WS.10).aspx

Checklist: Creating a certification hierarchy with an offline root certification authority:

=> http://technet.microsoft.com/en-us/library/cc737834(WS.10).aspx (superseded by: http://social.technet.microsoft.com/wiki/contents/articles/2900.aspx )

ADCS and firewall ports: http://blogs.technet.com/b/pki/archive/2010/06/25/firewall-roles-for-active-directory-certificate-services.aspx

ADCS FAQ: http://social.technet.microsoft.com/wiki/contents/articles/1587.active-directory-certificate-services-ad-cs-public-key-infrastructure-pki-frequently-asked-questions-faq.aspx

ADCS: Clean CA db

http://blogs.technet.com/b/askds/archive/2010/08/31/the-case-of-the-enormous-ca-database.aspx

ADCS: New Hotfix to fix the CA private key missing from system states backups:

http://support.microsoft.com/kb/2603469

AD CS – Permissions and delegation model:

http://technet.microsoft.com/en-us/library/cc732590.aspx

https://social.technet.microsoft.com/wiki/contents/articles/10942.ad-cs-security-guidance.aspx

AD CS tool to install: PKI smtp exit module

http://social.technet.microsoft.com/wiki/contents/articles/active-directory-certificate-services-smtp-exit-module-for-windows-server-2008-r2-example.aspx

ADCS NDES/SCEP:  http://www.microsoft.com/download/en/details.aspx?id=1607

http://www.windowsitpro.com/article/security/setting-up-network-device-enrollment-service-

ADCS CEP/CES: http://www.microsoft.com/download/en/details.aspx?id=1746

http://blogs.technet.com/b/askds/archive/2010/05/25/enabling-cep-and-ces-for-enrolling-non-domain-joined-computers-for-certificates.aspx

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM329

AD CS Online Responder Services (OCSP) in a Network: http://www.microsoft.com/download/en/details.aspx?id=17877

http://technet.microsoft.com/en-us/library/cc753468(WS.10).aspx

http://blogs.technet.com/b/askds/archive/2009/06/24/implementing-an-ocsp-responder-part-i-introducing-ocsp.aspx

AD CS Online Responder Services (OCSP) in high availability mode with NLB:

http://blogs.technet.com/b/askds/archive/2009/08/20/implementing-an-ocsp-responder-part-v-high-availability.aspx

 

ADCS deploying cross-forest certificate enrollment:

http://www.microsoft.com/download/en/details.aspx?id=17877

http://technet.microsoft.com/en-us/library/ff955845(WS.10).aspx

ADCS operations tasks: http://technet.microsoft.com/en-us/library/cc771702(WS.10).aspx

ADCS and Powershell: http://blog.powershell.no/2011/01/09/working-with-active-directory-certificate-services-from-windows-powershell/

Codeplex: PKI Powershell module: http://pspki.codeplex.com/

 

2013: Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy : http://technet.microsoft.com/en-us/library/hh831348.aspx

Certificate Services Concepts: http://technet.microsoft.com/en-us/library/cc778992(WS.10).aspx

Certificate Services Best practices: http://technet.microsoft.com/en-us/library/cc738786(WS.10).aspx

This step-by-step guide explains how to install and configure public key  infrastructure, based on:

  • Windows 2008 R2 Server core – offline Root CA
  • Windows 2008 R2 domain controller
  • Windows 2008 R2 enterprise edition – Subordinate Enterprise CA server

Offline Root CA – OS installation phase

  1. Boot the server using Windows 2008 R2 bootable DVD.
  2. Specify the product ID -> click Next.
  3. From the installation option, choose “Windows Server 2008 R2 (Server Core
    Installation)
    ” -> click Next.
  4. Accept the license agreement -> click Next.
  5. Choose “Custom (Advanced)” installation type -> specify the hard drive to
    install the operating system -> click Next.
  6. Allow the installation phase to continue and restart the server
    automatically.
  7. To login to the server for the first time, press CTRL+ALT+DELETE
  8. Choose “Administrator” account -> click OK to replace the account
    password -> specify complex password and confirm it -> press Enter ->
    Press OK.
  9. From the command prompt window, run the command
    bellow:
    sconfig.cmd
  10. Press “2″ to replace the computer name -> specify new computer name ->
    click “Yes” to restart the server.
  11. To login to the server, press CTRL+ALT+DELETE -> specify the
    “Administrator” account credentials.
  12. From the command prompt window, run the command
    bellow:
    sconfig.cmd
  13. Press “5″ to configure “Windows Update Settings” -> select “A” for
    automatic -> click OK.
  14. Press “6″ to download and install Windows Updates -> choose “A” to search
    for all updates -> Choose “A” to download and install all updates -> click
    “Yes” to restart the server.
  15. To login to the server, press CTRL+ALT+DELETE -> specify the
    “Administrator” account credentials.
  16. From the command prompt window, run the command
    bellow:
    sconfig.cmd
  17. In-case you need to use RDP to access and manage the server, press “7″ to
    enable “Remote Desktop” -> choose “E” to enable -> choose either “1″ or
    “2″ according to your client settings -> Press OK.
  18. Press “8″ to configure “Network settings” -> select the network adapter
    by its Index number -> press “1″ to configure the IP settings -> choose
    “S” for static IP address -> specify the IP address, subnet mask and default
    gateway -> press “2″ to configure the DNS servers -> click OK -> press
    “4″ to return to the main menu.
  19. Press “9″ to configure “Date and Time” -> choose the correct “date/time”
    and “time zone” -> click OK
  20. Press “11″ to restart the server to make sure all settings take effect ->
    click “Yes” to restart the server.

Offline Root CA – Certificate Authority server installation
phase

  1. To login to the server, press CTRL+ALT+DELETE -> specify the
    “Administrator” account credentials.
  2. Install Certificate services:
    start /w ocsetup.exe
    CertificateServices /norestart /quiet
  3. To check that the installation completed, run the command:
    oclist
    find /i "CertificateServices"
  4. Download the file “setupca.vbs”
    from:
    http://blogs.technet.com/b/pki/archive/2009/09/18/automated-ca-installs-using-vb-script-on-windows-server-2008-and-2008r2.aspx
    To:
    C:\Windows\system32
  5. Run the command bellow to configure the Root CA:
    Cscript /nologo
    C:\Windows\System32\setupca.vbs /is /sn
    <ca_server_name> /sk 4096 /sp "RSA#Microsoft
    Software Key Storage Provider" /sa SHA256
  6. In-order to verify that the installation completed successfully, open using
    Notepad, the file “_SetupCA.log” located in
    the current running directory, and make sure the last line is:
    Install
    complete! Passed
  7. Run the command bellow to enable remote management of the Root
    CA:
    netsh advfirewall firewall set rule group="Remote Service
    Management" new enable=yes
  8. Run the command bellow to stop the CertSvc service:
    Net stop
    CertSvc
  9. Run the command bellow to change new certificate validity period
    time:
    reg add
    HKLM\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\<rootca_netbios_name> /v
    ValidityPeriodUnits /t REG_DWORD /d 5 /f
    Note: The command above should be
    written in one line.
  10. Run the command bellow to start the CertSvc service:
    Net start
    CertSvc

Enterprise Subordinate CA – OS installation
phase

Pre-requirements:

  • Active Directory (Forest functional level – Windows 2008 R2)
  • Add “A” record for the Root CA to the Active Directory DNS.
  1. Boot the server using Windows 2008 R2
    Enterprise Edition
    bootable DVD.
  2. Specify the product ID -> click Next.
  3. From the installation option, choose “Windows Server 2008 R2 Enterprise Edition Full
    installation
    ” -> click Next.
  4. Accept the license agreement -> click Next.
  5. Choose “Custom (Advanced)” installation type -> specify the hard drive to
    install the operating system -> click Next.
  6. Allow the installation phase to continue and restart the server
    automatically.
  7. To login to the server for the first time, press CTRL+ALT+DELETE
  8. Choose “Administrator” account -> click OK to replace the account
    password -> specify complex password and confirm it -> press Enter ->
    Press OK.
  9. From the “Initial Configuration Tasks” window, configure the following
    settings:

    • Set time zone
    • Configure networking – specify static IP address, netmask, gateway, DNS
    • Provide computer name and domain – add the server to the domain
    • Enable Remote Desktop
  10. In-order to be able to remotely manage the Root CA, run the command
    bellow:
    cmdkey /add:<RootCA_Hostname>
    /user:Administrator /pass:<RootCA_Admin_Password>

Enterprise Subordinate CA – Certificate Authority server
installation phase

Pre-requirements:

  • DNS CNAME record named “wwwca” for the Enterprise Subordinate CA.
  1. To login to the server, press CTRL+ALT+DELETE -> specify the credentials
    of account member of “Schema Admins”, “Enterprise Admins” and “Domain Admins”.
  2. Start -> Administrative Tools -> Server Manager.
  3. From the left pane, right click on Roles -> Add Roles -> Next ->
    select “Web Server (IIS)
    -> click Next twice -> select the following role services:

    • Web Server
    • Common HTTP Features
    • Static Content
    • Default Document
    • Directory Browsing
    • HTTP Errors
    • HTTP Redirection
    • Application Development
    • .NET Extensibility
    • ASP
    • ISAPI Extensions
    • Health and Diagnostics
    • HTTP Logging
    • Logging Tools
    • Tracing
    • Request Monitor
    • Security
    • Windows Authentication
    • Client Certificate Mapping Authentication
    • IIS Client Certificate Mapping Authentication
    • Request Filtering
    • Performance
    • Static Content Compression
    • Management Tools
    • IIS Management Console
    • IIS Management Scripts and Tools
    • IIS 6 Management Compatibility
    • IIS 6 Metabase Compatibility
  4. Click Next -> click Install -> click Close.
  5. From the left pane, right click on Features -> Add Features -> Next
    -> expand “Windows Process Activation Service” -> select “.NET
    Environment” and “Configuration APIs” -> select the feature “.NET Framework
    3.5.1 Features” -> click Next -> click Install -> click Close.
  6. From the left pane, right click on Roles -> Add Roles -> Next ->
    select “Active Directory Certificate
    Services
    ” -> click Next twice -> select the following role
    services:

    • Certification Authority
    • Certification Authority Web Enrollment
    • Certificate Enrollment Policy Web Service
  7. Click Next.
  8. Configure the following settings:
    • Specify Setup Type: Enterprise
    • CA Type: Subordinate CA
    • Private Key: Create a new private key
    • Cryptography:
      Cryptographic service provider (CSP): RSA#Microsoft
      software Key Storage Provider
      Key length: 2048
      Hash algorithm SHA256
    • CA Name:
      Common name: specify here the subordinate server NetBIOS
      name
      Distinguished name suffix: leave the default domain settings
    • Certificate Request: Save a certificate to file and manually send it later
    • Certificate Database: leave the default settings
    • Authentication Type: Windows Integrated Authentication
    • Server Authentication Certificate: Choose and assign a certificate for SSL
      later
  9. Click Next twice -> click Install -> click Close.
  10. Close the Server Manager.
  11. Start -> Administrative Tools -> Certification Authority
  12. From the left pane, right click on “Certification Authority (Local)” ->
    “Retarget Certification Authority” -> choose “Another computer” -> specify
    the RootCA hostname -> click Finish.
  13. Right click on the RootCA server name -> Properties -> ->
    Extensions tab -> extension type: CRL Distribution Point (CDP):

    • Uncheck “Publish Delta CRLs to this location”.
    • Mark the line begins with “LDAP”, and click remove.
    • Mark the line begins with “HTTP”, and click remove.
    • Mark the line begins with “file”, and click remove.
    • Click on Add -> on the location, put:
      http://wwwca/CertEnroll/<RootCA_Server_Name>.crl
    • Click on the line begins with “HTTP”, and make sure the only option checked
      is: “Include in CDP extension of issued certificates”.
    • Click on the line begins with “C:\Windows”, and make sure the only option
      checked is: “Publish CRLs to this location”
  14. Extensions tab -> extension type: Authority Information Access (AIA):
    • Mark the line begins with “LDAP”, and click remove.
    • Mark the line begins with “HTTP”, and click remove.
    • Mark the line begins with “file”, and click remove.
    • Click on Add -> on the location, put:
      http://wwwca/CertEnroll/<RootCA_Server_Name>.crt
  15. Click OK and allow the CA server to restart its services.
  16. From the “Certification Authority” left pane, right click on “Revoked
    certificates”-> Properties:

    • CRL publication interval: 180 days
    • Make sure “Publish Delta CRLs” is not checked
    • Click OK
  17. Right click on the CA name -> All tasks -> Stop service
  18. Right click on the CA name -> All tasks -> Start service
  19. Run the commands bellow from command line, to configure the Offline Root CA
    to publish in the active-directory:
    certutil.exe -setreg ca\DSConfigDN
    "CN=Configuration,DC=mycompany,DC=com"
    certutil.exe -setreg
    ca\DSDomainDN "DC=mycompany,DC=com"
    Note: Replace
    DC=mycompany,DC=com
    according to your domain name.
  20. From the “Certification Authority” left pane, right click on “Revoked
    certificates”-> All tasks -> Publish -> click OK.
  21. Close the “Certification Authority” snap-in and logoff the subordinate CA
    server.
  22. Login to a domain controller in the forest root domain, with account member
    of Domain Admins and Enterprise Admins.
  23. Copy the file bellow from the Offline Root CA server to a temporary folder
    on the domain
    controller:
    C:\Windows\System32\CertSrv\CertEnroll\*.crt
  24. Start -> Administrative Tools -> Group Policy Management.
  25. From the left pane, expand the forest name -> expand Domains -> expand
    the relevant domain name -> right click on “Default domain policy” ->
    Edit.
  26. From the left pane, under “Computer Configuration” -> expand Policies
    -> expand “Windows Settings” -> expand “Security Settings” -> expand
    “Public Key Policies” -> right click on “Trusted Root Certification
    Authorities” -> Import -> click Next -> click Browse to locate the CRT
    file from the Root CA -> click Open -> click Next twice -> click Finish
    -> click OK.
  27. Logoff the domain controller.
  28. Return to the subordinate enterprise CA server.
  29. Start -> Administrative Tools -> Certification Authority.
  30. From the left pane, right click on “Certification Authority (Local)” ->
    “Retarget Certification Authority” -> choose “Another computer” -> specify
    the RootCA hostname -> click Finish.
  31. Right click on the RootCA server name -> All Tasks -> Submit new
    request -> locate the subordinate CA request file (.req) -> Open.
  32. Expand the RootCA server name -> right click on “Pending Requests” ->
    locate the subordinate CA request ID according to the date -> right click on
    the request -> All Tasks -> Issue.
  33. From the left pane, click on “Issued Certificates” -> locate the
    subordinate CA request ID -> right click on the request -> All Tasks ->
    “Export Binary Data” -> choose “Binary Certificate” -> click “Save binary
    data to a file” -> click OK -> specify location and the file name –
    <subordinate_ca_server_name_signed_certificate>.p7b
    -> click Save.
  34. Run the command bellow from command line to avoid offline CRL
    errors:
    Certutil.exe -setreg ca\CRLFlags
    +CRLF_REVCHECK_IGNORE_OFFLINE
  35. From the left pane, right click on “Certificate Authority” -> “Retarget
    Certification Authority” -> choose “Local computer” -> click Finish.
  36. Right click on the subordinate CA server name -> All Tasks -> “Install
    CA Certificate” -> locate the file <Subordinate_CA_Server_Name_Signed_Certificate>.p7b
    -> click Open.
  37. Right click on the subordinate CA server name -> All Tasks -> Start
    Service.
  38. Right click on the subordinate CA server name -> Properties -> ->
    Extensions tab -> extension type: CRL Distribution Point (CDP):

    • Mark the line begins with “HTTP” -> click Remove -> click Yes.
    • Mark the line begins with “file” -> click Remove -> click Yes.
    • Click on Add -> on the location, put:
      http://wwwca/CertEnroll/<subordinate_CA_Server_Name&gt;.crl
    • Click on the line begins with “HTTP”, and make sure the following options
      are checked: “Include in CRLs” and “Include in the CDP”.
  39. Extensions tab -> extension type: Authority Information Access (AIA):
  40. Click OK and allow the CA server to restart its services.
  41. From the “Certification Authority” left pane, right click on “Revoked
    certificates”-> All tasks -> Publish -> click OK.
  42. Close the “Certification Authority” snap-in
  43. Copy the files bellow from the Root CA to the subordinate CA (same
    location):
    C:\Windows\System32\CertSrv\CertEnroll\*.crl
    C:\Windows\System32\CertSrv\CertEnroll\*.crt
  44. Logoff the subordinate CA server.
  45. Login to a domain controller in the forest root domain, with account member
    of Domain Admins and Enterprise Admins.
  46. Copy the file bellow from the subordinate CA server to a temporary folder on
    the domain controller:
    C:\Windows\System32\CertSrv\CertEnroll\*.crt
    – copy the newest file
  47. Start -> Administrative Tools -> Group Policy Management.
  48. From the left pane, expand the forest name -> expand Domains -> expand
    the relevant domain name -> right click on “Default domain policy” ->
    Edit.
  49. From the left pane, under “Computer Configuration” -> expand Policies
    -> expand “Windows Settings” -> expand “Security Settings” -> expand
    “Public Key Policies” -> right click on “Intermediate Certification
    Authorities” -> Import -> click Next -> click Browse to locate the CRT
    file from the subordinate CA server -> click Open -> click Next twice
    -> click Finish -> click OK.
  50. Logoff the domain controller.

If you want to use Subject Alternative Names on internal SSL certificates issued by Active Directory Certificate Services you have to configure CA (Certificate Authority)
to accept SAN attribute from a certificate request.

By default (for security reasones) the AD CS CA does not issue certificates with SAN attribute.

Ability to connect without certificate issues (warning) to internal web server using a CNAME alias, FQDN or NetBios is one example where this becomes useful.

Run the following commands to configure CA:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc

net start certsvc

 

To add Subject Alternative Name to certificate add following to it’s attributes:

san:dns=dns_name

where dns_name is required Subject Alternative Name.

You can specify more names by separating them with an ampersand (&).

san:dns=dns_name1&dns=dns_name2

AD CS will accept the request and issue a certificate with Subject Alternative Names in it.

Remember to edit https bindings after installing certificate on your internal server (IIS).

Follow this reference guide from Technet: How to Request a Certificate With a Custom Subject Alternative Name: http://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx#BKMK_Security

Another interesting web article with configuration sample: http://www.ldap389.info/en/2011/04/29/powershell-enterprise-ca-pki-create-san-certificate-iis-7-server-we/