Types of certificate Authorities:
Root and subordinate CAs
A root CA is meant to be the most trusted type of CA in an organization’s PKI. If the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization becomes vulnerable. Therefore, both the physical security and the certificate issuance policy of a root CA are normally more rigorous than those for subordinate CAs. While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.
A subordinate CA is a CA that has been issued a certificate by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other CAs that are more subordinate. Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.
Enterprise and stand-alone CAs
An Enterprises CA Requires access to Active Directory Domain Services (AD DS).Uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. Publishes user certificates and certificate revocation lists (CRLs) to AD DS. An enterprise CA issues certificates based on a certificate template. The following functionality is possible when you use certificate templates. The certificate subject name can be generated automatically from the information in AD DS or supplied explicitly by the request. Autoenrollment can be used to issue certificates.
A stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet. When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request. The administrator has to perform these tasks because the certificate requester’s credentials are not verified by the stand-alone CA. Certificate templates are not used.
Supported Server edition: Enterprises & Datacentres.
Needs ADDS, DNS, Static IP, Time Synchronization
Server1 — 10.10.10.1— dc.sign.com
Server2 — 10.10.10.2— ca1.sign.com
Server3 — 10.10.10.3— ca2.sign.com
CONFIGURING ROOT CA:
Step1: Logon to server2 as domain admin member.
Install Root CA: go to server manager-Add Roles- select Certification Authority and click next.
Step2: select Standalone on setup type page and click next.
Step3: Select root CA on CA type page.
Step4: select create a new private key option and click next.
Step5: on cryptography for CA page u can select different CSP, hash algorithm and key length according to your need and click next.
Step6:On CA name page you can specify a CA name or leave it default and click next.
Step7: On certificate database page you can assign data base location or leave it default, click next and click finish.
By default, the Windows 2008 root CA will include AIA and CDP (CRL Distribution Point) information in the root CA certificate. If you want to specify this information, you must change or delete the [CRLDistributionPoint] and [AuthorityInformationAccess] extensions.
The following variables can be used in CDP & AIA extensions:
%1— ServerDNSName (fqdn)
%2— ServerShortName (Netbios)
%3— CA Name
%5— Domain DN
It is advised to review all important settings before continuing.
You can get all current settings by running the following command line command :
Certutil –getreg CA
The settings that will require your attention are:
[CRLPeriod, CRLPeriodUnits, CRLOverlapUnits, CRLOverlapPeriod, ValidityPeriod, ValidityPeriodUnits ]
You can define/change these settings using the certutil commands:
Certutil -setreg CA\CRLPeriod “Years”
Certutil -setreg CA\CRLPeriodUnits 1
Certutil -setreg CA\CRLOverlapPeriod “Months”
Certutil -setreg CA\CRLOverlapUnits 1
Certutil -setreg CA\ValidityPeriod “Years”
Certutil -setreg CA\ValidityPeriodUnits 12
Note: If you mistype a regkey, you will not get a warning or error. Certutil will simply create a new registry key without further notice. You can find all registry keys under HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\My Root CA
CONFIGURING ISSUING CA:
Step8: Log on to Server3 as domain admin member.
Install Subordinate CA: go to server manager-Add Roles- select Certification Authority, web enrolment and Online Responder and click next.
Step9: Select Enterprises option because you are about to configure an online issuing CA and click next.
Step10: On CA type page select subordinate CA and click next.
Step11: You can specify a common name for this ca on ca name page and click next.
Step12: On Request Certificate from parent CA page u can choose any one of two option to create a certificate request and click next and finish.
Step13: After installing the Issuing CA, we need to get the certificate signed by the root CA.
By Default, the Request file created on this location “c:\*req”. Copy this file to Root ca Shared Folder.
Go to Root Ca, Certification Authority- Rc on CA name- All Tasks – Submit New Request- Select the request file from shared folder. After that go to Pending Requests- right-click on the pending request and choose “Issue”. Open the certificate from Issued Certificates- go to the “Details” tab-click “Copy to file”.-Click “next” on the Welcome screen-Select P7B format, make sure to select “Include all certificates in the certification path if possible”-save this file to Issuing CA’s Shared folder.
Came back on Issuing CA, Open Certificate Authority MMC, right click the Issuing CA name and choose “All Tasks – Install CA Certificate”-Browse certificate from shared folder-Restart CA.
Configure OCSP Response signing Certificate
Step14: Server manager- Roles-ADCS-Certificate Template- Rc the “OCSP Response Signing” template-click “Duplicate Template”-Choose server version-ok-Type the name of template under general tab-on “security” tab, under “Group or user name”, click “Add” to open the “Select Users, Computers or Groups” dialog box, Click “Object Types”, select the “Computers” check box, and then click “OK”-Type the ORS computer name and select the name, click “ok”, Click on ors computer name and in the permission dialog box select “Read, Enroll and Auto Enroll” check boxes. You also configure security to this template for authenticated Users Groups and computer(OR).
IMPORT OCSP TEMPLATE TO CA
Step15: After define AIA extension, go to CA- rc on “Certificate Template”-New Certificate Template To Issue- In Enable Certificate Templates, select the OCSP Response Signing template and any other certificate templates that you configured previously, and then click OK.
(Open Certificate Templates, and verify that the modified certificate templates appear in the list.)
CREATE A REVOCATION CONFIGURATION:
Step16: Go to Server manager-Roles- ADCS-Online Responder-rc on Revocation configuration-Add Revocation Configuration-Name of revocation configuration- click “Select a certificate for an existing enterprise CA”.
Step17: Browse a CA certificate published in AD, Browse and select a name of CA that u want to associate with your revocation configuration(where OCSC signing certificate resides)-Revocation provider page, click on Provider and add provider location for both Base & Delta Crl’s (http://FQDN_computer_name/CertEnroll/CA_name)-ok-finish.
Step18: To check Revocation Certificate status go to server manager/Roles/ADCS/Online Responder/Array configuration/CA name.
CONFIGURING CDP/AIA EXTENSIONS FOR ONLINE RESPONDER:
Step19: ADCS-Rc on CA _name – Properties-extensions-CDP/AIA-Add. AIA for Online Responder: “http://OR_FQDN name/ocsp”.(select only “include in the OCSP extension” )
Step20: To check CA status go to server manager/Roles/ADCS/Enterprise PKI/CA name.
Configure Auto Enrolment:
Logon to Domain system, go to Group Policy Management-Default Domain Policy-rc Edit-Computer Configuration-policies-windows setting-Security setting-public key policies-certificate service client-auto enrolment-enable it.
Configure a CA to accept a SAN (Subject Alternet Name) attribute from a certificate request
Note: If your Organization includes more than one domain, i.e. Mail.domain.com and mail2.domain.com, you need a SAN certificate.
By default, a CA that is configured on a Windows Server 2008 does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behaviour, run the following commands at a command prompt on the server that runs the Certification Authority service. Press ENTER after each command.
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Create and submit a Server certificate request
When you submit a certificate request to an enterprise CA, the certificate template must be configured to use the SAN in the request instead of using information from the AD directory service.
Open internet explorer and type “https://servername/certsrv”.
After connecting Click Request a Certificate> Click Advanced certificate request> Click Create and submit a request to this CA > In the Certificate Template list, click Web Server and configure other properties as follows:
If you see the Certificate Issued Web page, click Install this Certificate.
To check ocsp location select OCSP and click Retrive.
To check revocation locations select either Certs or CRLs and click Retrieve.
To verify an certificate run: certutil –verify C:\filename.cer >verifyresults.txt
Result will look like given below.
To test connectivity run:
certutil –config FQDN\CAName –ping
Deploying the Root CA Certificate:
If the computers are apart from Domain:
Certuil –addstore –f Root Cert_name.cer
If the computers are part of the domain:
Certutil –dspublish –f Cert_name.cer RootCA