Step 1
Certificate requirements
1.
Where certificates will be used
a.
Locations where certificates will be deployed
b.
Locations where certificates will be validated
c.
Validate with business
Legal, government or regulatory requirements
Implications
of using certificates for encryption fully understood
Step 2
Root certification authority
1.
Determine the number of root CAs
a.
Business unit, division, or location
b.
Application or services
2.
Determine the root CA type and location
a.
Stand-alone root CA
b.
Enterprise root CA
c.
External root CA
|
Requirement
|
Stand-alone root CA
|
Enterprise root CA
|
|
Must be online
|
N
|
Y
|
|
Supports enterprise subordinate CA
|
Y
|
Y
|
|
Supports stand-alone subordinate CA
|
Y
|
N
|
|
Supports automated certificate management
|
Y – by using an enterprise subordinate CA
|
Y
|
Step 3
Certification authority hierarchy
1.
Determine the number of issuing CAs
a.
Regulatory requirements
b.
Political and organizational reasons
c.
Low bandwidth locations
d.
Fault tolerance
2.
Determine the number of intermediate CAs
a.
Additional intermediate CAS
b.
Each intermediate CA fault tolerant
Step 4
1.
Design certificate services roles
|
Service
|
HTTP/S
|
AD DS
|
OCSP
|
|
Enrollment
|
Y
|
Y
|
N
|
|
Validation
|
Y
|
Y
|
N
|
|
Revocation
|
Y
|
Y
|
Y
|
2.
Design CA servers
3.
Design IIS servers
|
IIS role
|
Protocol
|
IIS failover clustering
|
|
Certificate enrollment
|
HTTPS
|
Y
|
|
Certificate validation
|
HTTP
|
Y
|
|
CRL publication
|
HTTP
|
Y
|
|
Online responder for OCSP
|
HTTP
|
Not supported. Use
load-balanced array or hardware load balancer.
|
No comments:
Post a Comment