ADCS Tip and Tricks: Difference between revisions

From WikiWiki
Jump to navigation Jump to search
No edit summary   (change visibility)
No edit summary   (change visibility)
Line 1: Line 1:
[[ADCS]]
* Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server. (http://blogs.technet.com/b/configmgrteam/archive/2009/05/01/how-to-publish-the-crl-on-a-separate-web-server.aspx)
* Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server. (http://blogs.technet.com/b/configmgrteam/archive/2009/05/01/how-to-publish-the-crl-on-a-separate-web-server.aspx)
* A certificate from KRA (a) is added to the CA configuration. From that point in time on, the CA has access to the KRA's public key. If an archival request comes in, the CA is able to encrypt the random symmetric encryption key (used to encrypt the end-entity private key) with the KRA’s public key. Due to the fact, that the certificate from KRA (b) is added to the CA configuration after the end-entity private key was archived, KRA (b) is not able to recover the end-entity private key. You may assume, that the CA is doing an implicit re-encryption of the already archived private keys when a new KRA certificate is added to the CA configuration '''but it’s not'''! (http://blogs.technet.com/b/pki/archive/2009/08/07/understanding-key-archival.aspx)
* A certificate from KRA (a) is added to the CA configuration. From that point in time on, the CA has access to the KRA's public key. If an archival request comes in, the CA is able to encrypt the random symmetric encryption key (used to encrypt the end-entity private key) with the KRA’s public key. Due to the fact, that the certificate from KRA (b) is added to the CA configuration after the end-entity private key was archived, KRA (b) is not able to recover the end-entity private key. You may assume, that the CA is doing an implicit re-encryption of the already archived private keys when a new KRA certificate is added to the CA configuration '''but it’s not'''! (http://blogs.technet.com/b/pki/archive/2009/08/07/understanding-key-archival.aspx)

Revision as of 10:18, 23 May 2016

ADCS

  • Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server. (http://blogs.technet.com/b/configmgrteam/archive/2009/05/01/how-to-publish-the-crl-on-a-separate-web-server.aspx)
  • A certificate from KRA (a) is added to the CA configuration. From that point in time on, the CA has access to the KRA's public key. If an archival request comes in, the CA is able to encrypt the random symmetric encryption key (used to encrypt the end-entity private key) with the KRA’s public key. Due to the fact, that the certificate from KRA (b) is added to the CA configuration after the end-entity private key was archived, KRA (b) is not able to recover the end-entity private key. You may assume, that the CA is doing an implicit re-encryption of the already archived private keys when a new KRA certificate is added to the CA configuration but it’s not! (http://blogs.technet.com/b/pki/archive/2009/08/07/understanding-key-archival.aspx)
  • In-place upgrades directly from Windows Server 2003 with Service Pack 2 or Windows Server 2003 R2 to Windows Server 2012 R2 are not supported. If you are running an x64-based computer, you can upgrade the CA role service from Windows Server 2003 with Service Pack 2 or Windows Server 2003 R2 to Windows Server 2008 or Windows Server 2008 R2 first and then upgrade to Windows Server 2012 R2 or Windows Server 2012. (https://technet.microsoft.com/en-US/library/dn486797.aspx)