Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Infrastructure Saturday 2011 - Understanding PKI and Certificate Services
Similar to Infrastructure Saturday 2011 - Understanding PKI and Certificate Services (20)
More from kieranjacobsen
More from kieranjacobsen (12)
Recently uploaded
Recently uploaded (20)
Infrastructure Saturday 2011 - Understanding PKI and Certificate Services
- 1. KIERAN JACOBSEN HP Understanding PKI and Certificate Services Gold Sponsors Silver Sponsors
- 2. Why Should I care? Contoso Requirements Design Considerations CA Hierarchy CA Lifespan Physical or Virtual? Private key storage Key lengths Certificate Revocation lists AIA and CDP Locations Stuff we missed… Ouch! Pain Points PowerShell to the rescue AGENDA
- 3. Why Should I Care? There are a number of technologies which need PKI Cloud Infrastructure Federated identity systems. E.G. ADFS HTTPS/SSL SMTPS Multi factor authentication. E.G. Smart cards SMIME Encrypting File System (EFS) Code signing 802.1x Authentication and/or NAP Remote Desktop Services Many organizations have legal requirements for PKI with serious financial or legal ramifications for a breach of that infrastructure!
- 4. Contoso Requirements Contoso is developing a new web application suite ADFS to provide SSO Almost 1million end users 3rd party certificates for HTTPS Private certificate infrastructure for internal use Network is segregated into internal/corporate and perimeter networks. Certificates will be in use both in the corporate and perimeter networks Use of certificates to be extended to other applications, remote access, partners and 3rd parties at a later date. High availability and continuity planning is a must
- 5. Protecting your privates The first rule of security in PKI, is protect the private key! Protecting private key of authorities is absolutely critical If a bad guy has access to your private key or can determine your private key…
- 6. CA Hierarchy Single/One Tier Root and Issuing CA on are the same Simple to manage Hard to manage if a breach occurs Not RECOMMENDED!
- 7. CA Hierarchy Single/One Tier Two Tier Root and Issuing CA on are the separated Slightly more difficult to manage Security breach of issuing CA easy to manage Highly scalable RECOMMENDED!
- 8. CA Hierarchy Single/One Tier Two Tier Three Tier Root, Policy and Issuing CA separated Quite difficult to manage Security breach of issuing CA easy to manage Very highly scalable Not RECOMMENDED!
- 9. CA lifespan Certificate Expiry = Date of certificate issue + Validity period Validity period defined by: Certificate Template CA Policy Expiry Date of CA’s certificate Certificates cannot be issued by an authority with a expiry which is after the expiry of the authorities own certificate A subordinate authority cannot have its certificate expiry to longer than its superior authority. I..E. In a two tier hierarchy, issuing CA certificates must have an expiry that is before the Offline Root CA. When an authorities certificate expires: All certificates will have, logically, expired Cannot sign CRL files!
- 10. CA lifespan 2 Validity period factors: Deploying an authority is a lot of work Certificates issued must expire before authorities certificate Subordinate authorities must expire before superior authorities Are we going to renew CA certificates or replace? When are we going to start the work? Recommended Validity Periods Offline Authorities: 10 to 25 years Issuing Authorities: 5 to 10 years Replacement Schedule -> Validity Period Replace at 75% Replace at 90% 5 years 3 years, 9 months 4 years, 6 months 10 years 7 years, 6 months 9 years 15 years 11 years, 3 months 13 years, 6 months 20 years 15 years 18 years 25 years 18 years, 9 months 22 years, 6 months
- 11. Physical or Virtualized Hardware Physical Hardware Virtualized Hardware dependent Hardware Independent Strong private key protection Weaker private key protection Hard to replicate Easy to replicate Hard to make highly available Highly available by nature Additional key protection options available Only encryption available as an additional layer of protection
- 12. Private key storage By default, private keys are stored in Local Certificate Store Local Certificate Store is vulnerable to: Security vulnerability in software API controlling access Can bypass API with physical access to storage/server Risk mitigation by : Encrypting Operating System disk with Bit Locker Storing physical disk media in a safe Storing Private keys in USB Tokens, Smart cards Ultimate security: Hardware Security Module (HSM)
- 13. Key Length Offline authorities (root and policy): 4096 bits Issuing authorities: 2048 bits Certificates: 2048 bits Avoid using keys of 1024 bits and 512bits.
- 14. Certificate Revocation Lists CRL: Certificate Revocation List A list of all the certificates clients should not trust Signed by a the certificate authority which issued the list Each authority will maintain its own list Released on a regular time, generally hourly, daily, weekly, monthly, 6 monthly or yearly. Valid for a limit period of time. The time period is slightly longer than release schedule Delta files can be used
- 15. AIA & CDP AIA: Authority Information Access -> used to help validate a certificate is trusted CDP: CRL Distribution Point -> Used to determine a certificates revocation status Protocols allowed: LDAP, HTTP, FTP and UNC Paths Placement of locations Corporate Network DMZ/Permiter External? Cloud? How to we ensure locations are highly available?
- 16. AIA & CDP at Contoso LDAP LDAP location based off corporate domain, contoso.local Only systems in corporate network will have access HTTP HTTP location based of certs.contosocorporation.com Server to be in perimeter network All locations internally have access to this location External access easily made available at a later date
- 17. Other things to consider Use Sensible names Define corporate policy: Certificate Policy (CP) Certificate Practice Statement (CPS) Auto Enrollment Online Certificate Status Protocol (OCSP) Key Archival
- 18. Deployment summary Hierarchy: 2 Tier – Offline Root and Single Issuing CA Lifespan: Offline: 25 years, to be replaced in 22 ½ years Issuing: 5 years, to be replaced in 4 ½ years Private Key/Hardware: All Virtual Key Lengths: Offline: 4096bits Issuing: 2048bits CRL: Offline: Every 6 Months Issuing: Base Weekly, Delta Daily AIA/CDP Locations: LDAP: Contoso.local corporate AD HTTP: certs.contosocorporation.com
- 19. OUCH!! Pain points! CA hashing algorithms LDAP for a CRL and AIA distribution point ADFS requires specific CA Template versions AIA specification bug
- 20. PowerShell to the rescue CRL Monitoring and validation Backups Private Key backups CRL Publishing
- 21. question and answer time useful links My Website: http://aperturescience.su PowerShell CRL Copy by PKI Blog: http://bit.ly/v5Buuf Designing and Implementing a PKI by Directory Services Team: http://bit.ly/tuf0T6 Gold Sponsors Silver Sponsors PRIZES Submit your feedback to WIN. $2650 worth of training from Voyager PRO UC headset. 20% off all books @ MSPress Code ISBRIS
Editor's Notes
- Welcome everyone. My name is Kieran Jacobsen, many of you know me from user group meetings and TechEd, others from my time as a student ambassador. To get to know you all, and your experience in the field, could those of you who have deployed certificate services of some variety, be it Microsoft or something else please raise your hand?Now raise your had if you solution was something more complex than a single certificate authority?Now how many of you actually designed and documented your solution, be it a single authority for a complete hierarchy? Well lets begin. Today I will be taking you on a journey through the design process for a public key infrastructure solution. Approximately 18 months ago, when I was with a different company, I was just a system administrator who had only minor experience in PKI, I had learnt about PKI at university, even went so far as tutoring public key cryptography. I had deployed some simple certificate authorities for various projects, but the project that I had just landed on required something completely different from what I had seen before. The content and examples contained in this presentation are derived from that project.
- So what will we be covering?Firstly, I am going to give you some good reasons to care about PKI, and certificates, and why you should deployment correctly.Once we understand the importance, we will begin our journey by covering off the PKI requirements for the project, using the usual Contoso examples. From there I will guide you through all the major design considerations that are important not only for the example project, but I feel are important for all PKI deployments. I will finish off with a few items that caused significant pain for me, and how PowerShell came to help me.I will warn you all, I am going to be throwing quite a bit of PowerPoint slides at you. I am really sorry, but the topic is hard for me to do many demos on, and there is a lot of information to be shared.
- Why should we, as IT professionals, care about public key infrastructure?Every organization has some investment in certificates and pki. Most organizations do not realize that they have this investment, let alone do they realize how crucial this investment is to the day to day running of the business.So where would we start with a list of technologies which have a dependence on PKI? Let’s start with the word you will probably hear quite a lot today. THE CLOUD! Cloud infrastructure needs PKI, Azure in particular makes use of certificates for authentication. With this growth of the companies moving to the cloud, the use of federated identity systems such as ADFS has become more popular. These systems use certificates to trust each other, as well as using certificates to encrypt and sign claims generated for users.The next few you should all recognize. These include HTTPS, SMIME, EFS, Smart Cards, code signing for signing our PowerShell scripts, 802.1x and NAP.Finally, Remote Desktop Services. Certificates can be used to allow a Remote Desktop Client to verify the identify of a server it is connecting to. By default a server will make use of a self signed certificate, using this will generate a warning on the client machine when it does to connect; most people will simply chose to ignore the warning or disable the check. It is quite easy to configure all of your servers to make use of a real certificate issued by your internal authority. It only takes about a dozen mouse clicks in group policy. Perhaps this is something Alan should demo one day.But seriously. Companies and even individuals can face some serious consequences for a security breach. With most companies moving to the internet, and government requirements pushing the use of SSL cryptography if not more, there can be some serious financial costs associated with a breach, not to mention possible legal costs. Now that we all care, lets begin our journey.
- Along time ago, in a galaxy far away, our friends Contoso were running some customer web applications, these were getting pretty old so they decided to develop a new suite of web applications. To provide a single sign on experience to customers and partners, ADFS was selected, and the need for a formalized PKI solution was identified.Contoso has previously used certificates from external authorities for any https applications which occur externally. External CA certs currently protect their customer portal, their webmail and remote access solution. This will continue into the future as well.Internally however, applications have previously made use of self signed certificates, or certificates which were issued by a management server. This management server was thrown together in a hurry with no design work occurring. Contoso would like to replace this authority with a solution based upon best practice, and whilst they will first only use the new certificates so to speak, for the new project; in the future they wish to go back and replace all of the legacy certificates in use. Another hope is that the new pki could be extended to remote access, and perhaps with partner organizations.Like most other environments, Contoso’s network is segregated into a corporate network where internal servers and employee workstations reside, and a perimeter network where web application servers running the new applications will exist. These networks have been separated by a firewall which restricts what traffic is allowed between the two networks, in particular, there is limited amount of network traffic allowed from the perimeter network to the corporate network. A similar firewall exists between the internet and the perimeter network. Applications needing certificates will reside in both the corporate and perimeter network.Finally, as all of this is highly visible to both customers and senior management, we should make sure there is a significant investment in the availability of the new PKI and the new web application suite. Contoso wants to provide customers with an almost 24/7 usability experience and high availability should be considered at every possible level. Contoso recently survived the Brisbane flooding and have set stringent goals on continuity planning.
- The first rule of security in public key cryptography and public key infrastructure is that above all else you must protect your private keys. Be it the private key for the certificate used for SSL on your website, or the root authority; we do not want to let the private key fall into the wrong hands! If a bad guy has access to your private key, or can determine your private key, then you are in serious trouble!
- So where do we start, well, lets start by defining the shape or structure of your public key infrastructure. The structure of your PKI is referred to as a certificate hierarchy. All hierarchies will start with a single authority, the topmost authority, called the root authority or the root CA. You will often hear the term trust anchor during discussions about a root authority as its this authority that your clients, servers and devices will trust. Hierarchies will always start with a root, but could have other subordinate authorities below them.If you have a root authority, and it doesn’t have any subordinate authorities below it, then the hierarchy is referred to as a single, or one tier hierarchy. The role of being trusted and the role of issuing certificates is performed by the same authority, which is simple to manage however for security reasons, these two roles should be separated. Whilst you may be tempted by the simple management, if the root ever suffers from a breach, or it reaches the end of its life, you are faced with quite a complex procedure to replace it. You will need to reconfigure all of your end point devices to not trust the old certificate authority and trust your new authority, and then reissue all of your certificates. During a breach, modifying certificate trusts isn’t the best use of your time.There is nothing wrong with a single tier, I have seen them deployed for all sorts of legitimate reasons, but in the end its just not very sensible. Single tier authorities are especially a source of problems when their deployment has no planning, design or documentation.
- Next we have two tier hierarchies. These consist of a root authority, however this time, the root has only issued certificates for one or more subordinate, issuing authorities. Now we have the role of being trusted, and the role of issuing certificates separated. Everything is still configured to trust the root CA, however due to the nature of pki, issued certificates will be trusted as they originate from a trusted authority, that is the root, via the subordinate authority.Once the root authority has issued certificates to the subordinates, it can be shutdown and we will only need to power it on to either issue more/new subordinate authorities with certificates, or to publish a certificate revocation list. Generally speaking, a root authority will only be required to run for approximately 30 minutes per year. This is the first step to protecting the root ca’s private key.The issuing authorities will take care of all of the requests and will remain online.In the event of a breach for an issuing ca, the process of replacing an issuing authority is quite simple. Power on the root, revoke the certificate for the subordinate, issue a new certificate, publish a new CRL, power off the root authority, and reissue the certificates previously issued. We will not be touching any of the end workstations directly, we are not editing the trusted authorities list.The ability to have multiple issuing authorities also increases the scalability of our PKI solution, we could use geolocation or a number of methods to balance incomming certificate requests across a number of online issuing authorities.Two tier hierarchies are generally suitable for most deployments. And in the case of contoso, it was felt that the deployment of a two tier hierarchy would meet their needs. (A single issuing authority would meet contoso’s requirement as they would not be handling a significant number of requests per day.,,..
- Finally we have a three tier hierarchy, which is similar to the two tier but there is an additional tier between the trusted root authority and the issuing authority. This additional tier is often called a policy or intermediate CA.Several reasons exist for the addition of this tier, firstly it could be a policy enforcement layer, restricting what types of certificates the authorities below can issue; secondly it could be an organizational or administrative boundary; finally we could implement a 3 tier hierarchy to reduce the risks of a breach and reduce the work required should we need to revoke a number of authorities in the event of a breach.Whilst three tier hierarchies are more secure than one or two tier, its significantly more complex to deploy and manage and thus it isn’t suitable for most organizations. If your organization needs the additional security, and can wear the additional deployment and management costs, then consider the use of a three tier hierarchy.
- Every certificate has a date where it expires. From that date, it should no longer be used, and will not be trusted.The expiry date is determine by adding the appropriate validity period to the date the certificate is issued. Expiry dates are a locked attribute for a certificate and cannot be changed.The validity period is specified by either the template a certificate was issued against, policy within a specific authority, or finally, it could be limited by the expiry date of the authorities own certificate.This is very important to point out. If I submit a certificate request based up a template which is normally valid for 2 years, but the authorities own certificate expires in 18 months; then the resulting certificate issued will expire in 18 months, not 24 months! A certificate authority simply cannot issue a certificate which has an expiry date after its own, this also applies for a authority issuing a certificate to a subordinate. For example, a root authority in a two tier hierarchy could have its certificate expire in 10 years time, the issuing authorities within this hierarchy cannot have an expiry of 15 years, they must have less than 10 years!I should also point out what When the validity period for a certificate authority expires, that is, when an authorities certificate expires, we will encounter several issues, firstly, all the certificates issued will have expired, secondly, we will be unable to sign CRL files. This will obvious render applications relying on our PKI pretty inoperable.
- By now you are probably thinking, Kieran, what validity periods should we be using? 5? 10? 20?There are a few things we should consider before we make a decision.PKI deployments shouldn’t be a regular activity, these deployments that your organization should do and then move on. We should select a period which ensures there is a sufficient amount of time between now and when we have to do all of this work againNext we need to remember what was just discussed, that authorities cannot issue certificates part their own expiry.The next thing to consider is, what will we do when an authorities certificate expires? Will we replace the authority completely with a new one, or replace the authorities public/private key pair, or will we simply renew the current certificate for the same period again? This leads on to the final decision. When in the lead up to the D day that is a certificate expiry, will we actually perform the necessary activities of replacing or renewing the authority?The recommendation from Microsoft is 10 years for offline authorities, be they root or intermediate, but many other groups will recommend upward of 20 to 25 years. I think 25 years is certainly suitable.Generally, for issuing authorities the recommendation is 5 years, with 10 occasionally thrown around as another possible option. I really do believe that 5 years is an appropriate length of time.Contoso decided their root would be around for 25 years, and issuing authorities valid for 5 years. They will work to replace, not renew an authority at the 90% mark.
- What hardware should we use? This is an important question and we need to consider it carefully.The issue with physical hardware is we are tied to a specific chunk of metal. If something happens to that particular hardware, our PKI is placed at risk, virtualization can provide us with increased availability. This risk could be general use in the case of the online authorities, or in the case of the offline authorities, the lack of use could pose a significant risk. Lets take a look at an example. Contoso’s root ca will be valid for 25 years. If we deploy it today, then it will have a maximum operation life until 2036, if we replace it at 90% it will still be around until 2033. How many of you have a server that is 22 years old? What would your management think if you showed them a 22 year old server in your data center? Whilst I would suspect you would be performing some upgrades over the 22 years, it is still a long time to be tied to specific hardware, and hence virtualization could be used here to remove the dependency on old hardware. Next, lets consider how often some of this hardware might actually get used, still looking at contoso’s root ca; it will most likely be powered on for 30 minutes per year on average with it remaining off for 8765 and ½ hours each year. Why would we not virtualize a server which will only be used for around 12 hours in total for its entire life?Another consideration is your availability requirements. If you need your issuing authorities to be highly available, say you are making use of smart card authentication and need to quickly issue new certificates, then how are you going to ensure its there when you need it? Clustering is certainly an option however virtualization gives you a high degree of availability but its very nature, more importantly, Virtualization gives us additional disaster recovery capabilities. Site to site replication is easy to perform in an environment where virtualization is in use.. As I previously mentioned, Contoso is greatly concerned about their disaster recovery process, what could be more simple than replicating the issuing authority across to their disaster recovery site? In the event of a disaster, all they need to do is power it back on. The replication options of virtualization should not be overlooked.The major issue with virtualization is that it limits us in how we can provide additional levels of protection to our private keys. Let’s take a look at private key protection mechanisms.
- The selection of an appropriate place to store a private key, influences the protection of it considerably.Windows by default will store private keys in the local certificate store for the computer account, which, which plainly put, is the local hard drive for the windows installation. This is by far the cheapest, simplest, and easiest location to store the key however it is not the most secure method. The use of the local certificate store leaves us vulnerable to a number of attacks, in particular, if we opt to use virtualization, there is the potential for an attacker to copy a virtual machine, and bypass the normal controls windows provides by copying files directly off the storage.The first level of protection against this sorts of attacks, and really the only option to virtualized authorities or deployments which do not want to incur much expenditure is to encrypt the operating system disk with Bit Locker. It is my opinion that bit locker should be used, for any authority be it physical, virtual, offline or online issuing.What if we have a physical authority, what options do we have then?Chip based authentication tokens, such as a smart card or usb token, are fairly cheap and easy to implement. The authorities private key will be stored there instead of the local certificate store in windows. For offline authorities, store the tokens away in a safe until required. Not all smart cards and tokens support being used to protect an authorities private key, and not all support large key lengths; you will need to ensure that whatever card or token you use support active directory certificate services and keys up to 4096bits long.For those after ultimate levels of protection, you cannot go any further than a Hardware Security Module or HSM. HSMs are physical devices which connect using serial, usb, pci or through the LAN. Once a server is connected to the HSM, a software interface allows the operating system to interact and perform various cryptographic functions with the private key, it will never fully reveal the key during normal operations. A HSM will also make use of hardware and software tamper protection mechanisms, and could be configured to destroy a private key if an attempt to tamper with the device is detected. Whilst the use of a HSM will greatly increase the protection of your private keys, they can be quite expensive and require a lot more management. They are generally only recommended to large enterprise environments, government, defense, financial institutions and the public certificate authorities.After reviewing the options available. Contoso decides to virtualize their authorities so they can easily make use of virtual guest replication for their disaster recovery planning.
- The length of your public/private key pairs is something I will cover quickly.Public key cryptography is secure due to the computational difficulty of factoring very large numbers. Whilst it was previously difficult for most attackers to factor a number which is represented by 512 or 1024 bits; with the growth of cloud computing, it is now possible and quite affordable to factor smaller numbers of these lengths. Due to this, larger numbers, hence larger key lengths should be used.It is now recommended that all offline authorities use 4096 bit length keys and everything else, both issuing authorities and end devices use 2048bit length keys.
- CRL, or certificate revocation lists, are files signed by the certificate authority which list the thumbprint of certificates which have been revoked and should not be trusted by an device, endpoint or application. Each authority is responsible for maintaining its own revocation list and each will be checked by endpoints as needed.When you configure an authority, you will need to specify how regularly you wish to release a new updated CRL file. CRL files will have a validity period, which will be slightly longer than how regularly new files are released. The overlap period is a safety mechanism to ensure the continuity of your PKI. Clients will cache a copy of the CRL file until a more up to date version is released. If a client or device has a copy of the CRL which has expired, and it cannot get access to a new valid CRL file, then it may reject even valid certificates. Failure to ensure that clients can access valid CRL files, can result in applications failing to function.There is also the option of Delta CRL files. Delta CRL files are partial CRl containing only entries for certificates that have been revoked since the last base CRL has been issued. The reason we use this is to reduce the amount of data our clients need to download. The use of more frequently updated deltas allows us to revoke certificates more quickly whilst reducing network data consumption required for downloading the base CRL which can be quite large.After a discussion with various interested parties, CRL publishing periods were decided as every 6 months for the offline root, and weekly for the issuing authority. Delta CRL files would also be used for the issuing authority and they would be published daily.
- When we are presented with a certificate, there are many factors we need to check before we can consider the certificate valid, two important factors are, does this certificate originate from a certificate authority we trust? And has this certificate been revoked?Two attributes are included on each certificate that help us with this process. These attributes are the AIA, or Authority Information Access and the CDP or CRL distribution point. The AIA allows us to trace a certificate back to a root authority we trust, whilst the CDP is a place we can go to, to download the latest CRL file for an authority. Certificate authorities my publish authority and CRL information to multiple AIA and CDPs, and all of them will be listed in a certificate when it is issued.AIA and CDP locations could be accessed via a number of protocols, LDAP, HTTP, FTP and UNC paths are all valid. However, LDAP and HTTP are generally the two most commonly deployed. Active Directory Certificate services will by default have LDAP, HTTP and UNC paths specified however it is recommended that you change away from the defaults.Significant time should be spent when determining what protocols you wish to provide for AIA and CDP access as well as where you will place servers offering that information. Don’t forget that if you are making use of certificates in externally, or using them in your DMZ or perimeter networks, that you offer locations and protocols that clients can use appropriately. If Internet clients are presented with a certificate and there is no valid AIA or CDP location for them to access, there is no reason for them to trust the certificates issued. Before deployment of certificate services, always ensure that ever device interacting with your PKI can access at least one AIA and CDP location listed in all of the certificates in the hierarchy.If you select to use LDAP, then most likely you will put the certificate information in active directory, which means it is highly available. But don’t forget about your applications and systems which cannot access LDAP, HTTP is most commonly accepted so ensure that at least one AIA and CDP location is HTTP based and that is accessible by most if not all; and don’t forget to make it highly available. Making the HTTP location highly available should be simple enough, its just a very small piece of web content after all.
- This was a difficult decision for contoso.Cotoso decided to have to locations listed for both AIA and CDP. The first would be an LDAP location based upon their internal corporate active directory domain. This location would obviously only be available to internal corporate devices.The second location would be HTTP based, with an external FQDN, stored on a server in the perimeter network. The external FQDN would allow opening up the distribution point to external parties and the internet very simple in the future; whilst the placement of the HTTP server in the DMZ/permiter network would make it accessible to almost every machine in their environment. Once again, the HTTP location wouldn’t be made xternally accessible to begin with, but the option is there.
- Look, there is just a few other things I don’t have time to cover, but you may wish to consider during your design process.Firstly, select sensible names for your authorities, roots should have names like Contoso Root Authority, and issuing authorities should have a number, as there could be quite a few of them. Issuing authorities could have a format like Contoso Issuing Authority 1.There are two corporate polices you should consider writing. The first is the Certificate policy or CP. This defines who gets certificates, and how they get certificates but will also cover who is allowed to issue certificates in the first place. Next you have the certificate practice statement, or CPS. This is similar to the CP but focuses on certificate authority operations and management of issued certificates. Who is liable in the case of a breach will be covered in the CPS. **The CPS will also cover how validation, renewal and revocation of certificate will be covered.** You should consider having a link to the CPS in every certificate issued by your CA.Another thing to consider is whether or not your organisation will be using auto enrolment as this can affect the placement of your authorities in your network, and what firewall rules might be needed.You should also decide if you want to use OCSP which is a web service based mechanism for checking certificate validity and revocation status.Finally, key archival is something you might want to perform. Key archival is a system for backing up the private keys of a certificates issued by an authority. Key archival is pretty important, and will generally be implemented for user certificates as a mechanism to retrieve data that users may encrypt with a personal certificate (for example EFS). There are arguments for and against this. I personally like it.
- Just a quick summary of everythingContoso has decided to deploy.2 tier hierarchy with an offline root and single issuing authority. All will be virtualized.The offline root will be valid for 25 years, and issuing 5 years. Both will be replaced at 90% of their validity period.Key lengths will be following the recommendations, 4096 for the offline and 2048 for the issuing authority.CRL will be published every 6 months for the offline root, weekly for the issuing. A delta will be published daily for the issuing as well.AIA and CDP to be available via LDAP on the corporate domain, and a DMZ based HTTP server with an external FQDN
- There were a few things that caused me some additional work, one or two were particularly nasty.When you add the ADCS role to a server, you will be asked what hashing algorithm should be used by the authority. Options will include SHA1, SHA256, SHA384 and SHA512. The later 3 come from the newly ratified SHA2 specification. At first, using the more secure SHA 2 algorithms might seem sensible, the temptation to use the super secure SHA 512 algorithm could be particularly tempting to some administrators. For the love of your own sanity. DO NOT SELECT IT! Windows XP and server 2003 have limited support for the SHA 2 algorithms, the smaller hash lengths are supported with additional patches, but at this point there is no SHA 2 512 support.Quickly, LDAP is a major pain. Since additional security was implemented in windows server 2003 and 2008, non windows and non domain joined machines can struggle with LDAP connectivity to your domain controllers. If probably isn’t worth the pain of even attempting to use LDAP as a AIA and CDP. ADFS makes use of certificates. The ADFS server will make use of 3 certificates; one will be just for plain old HTTPS traffic, but the other two, token signing and decryption. Whilst there are no specific requirements for your HTTPS traffic, there are for the token certs. The big issue, is that there isn’t much documentation about what extensions and options should be selected in the templates that these two certs are issued against. The other issue, which can be just as serious is that you need to ensure that the templates you use, are Windows Server 2003 based and not the newer Server 2008 certificate template version. Whilst the ADFS server configuration tool will accept certificates based upon the 2008 template, you may have issues with authentication.The final bug, is one which is unfortunately quite undocumented, and I haven’t heard back since I reported it. When you specify the AIA location of an authority, you also get the option of selecting the file name for the dot crt files which are produced. Most people will accept the default name, however one security advisor felt that including the FQDN of our offline root authority in the file name, could potentially leak information if and when we used the PKI externally. The first is simple, specify a different file name, windows happily accepts the new file name, and every certificate will have the right filename, however the certificate services service will always fail to make the file with the new filename. It will always generate the file with the default file name, no matter what is specified in the registry with the mmc snap in or command line utility. It is simple to workaround this issue, as the crt files don’t need to be updated once they are published to the correct locations, however it would still be preferred if the issue was resolved.
- PowerShell to the rescueFirstly, use PowerShell to monitor your environment, have it checking that publishing of CRLs working from various points of view. If you have different network segments, have a machine in each run a script performing basic CRL validation, for example, is the file accessible and does it have a valid date?Secondly, don’t forget to perform backups of your authorities. Oddly enough I didn’t find an enterprise backup solution which actually backed up everything necessary to restore an authority. I will post my simple backup script to my web site, or you can write your own. Don’t forget to perform a test restoration!Another issue with backups, is don’t leave your private key lying around. Back it up to removal media and secure it safely. Don’t have your script exporting the private key every day/week/month. Finally, PowerShell is of great assistance when it comes to automating the process of publishing CRL files to the CDP, in fact I cannot think of any better method. I have a script which will push the CRL files as well as files needed for the AIA to a server using SCP, which I will post online. I have one outstanding issue in that you need to be absolutely sure its running after your CRL is generated by the certificate services windows service. I found another script online, on the Windows PKI blog which provides similar functionality for UNC paths. My aim is to over the next few weeks finish off a more unified script which will also fix up the CRL scheduling issue.
- I would like to thank you all for coming.My website is aperture science dot su (aperturescience.su), I will be posting up the various PowerShell scripts there this week. Some of you might be a little surprised to see some other operating systems and technologies on my blog, but there is a considerable amount of powershell scripts there for you to use as well.Before I go to questions, I just want to point out a blog series by the Active Directory Services Team. This series covers a lot of very practical information on getting a correct Pki in place. You will see a lot of what I have covered today in this series. Now, any questions?STOP ON THIS SLIDE