Windows Root Certificate authority questions.

hello,
I have 2 questions with regards to Offline ROOT CA in a 2 TIER Hierarchy :
(1) Is it necessary to to ” map the Namespace of Active Directory to an Offline CA’s Registry Configuration” ? I didn’t do this step in my lab env and find this in some but
but not all the online posts as well. what happens if we don't run this command on offline CA ?
For instance:  certutil.exe –setreg ca\DSConfigDN CN=Configuration,DC=lab,DC=com 
(2) What happens if i do not publish the ROOT CA certificate via "certutil -dspublish -f xxx.cer ROOTCA " command but instead just  push the root certificate  using Default Domain Group Policy Object to "Trusted Root Auth" store
on all the domain machines ?  What are the pros/cons of using the certutil method vs the GPO method ?  
Thanks
Neeraj

> Is it necessary to to ” map the Namespace of Active Directory to an Offline CA’s Registry Configuration” ?
it is necessary only if you configure LDAP URLs for CRL Dsitribution Points and Authority Information Access extensions on Root CA (not recommended).
> What are the pros/cons of using the certutil method vs the GPO method ?  
different scopes. When publishing in Active Directory, it is downloaded to all
*forest* members, while GPO covers only limited scope (domain, site or OU).
Vadims Podāns, aka PowerShell CryptoGuy
My weblog: en-us.sysadmins.lv
PowerShell PKI Module: pspki.codeplex.com
PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
Check out new: SSL Certificate Verifier
Check out new:
PowerShell File Checksum Integrity Verifier tool.

Similar Messages

  • How to import a Root Certificate Authority for signing

    How can I import a Root Certificate Authority in order to use it with Certificate Assistant as a CA to sign other certs?
    I have the CA cert imported in keychain along with it's associated private key (from a .p12), it's got the gold icon and is recognized as a Root certificate authority, yet Certificate Assistant will not list it as an available Root CA in the "Set Default CA" action dialog, the "Add..." dialog seems only interested in a ".certAuthorityConfig" plist file.
    Do I have to generate a certAuthorityConfig for the CA? I can't seem to find a way to do that. No clues from certtool & security CLI utils even.
    Any info/leads on how to get this to work would be much appreciated.
    Regards,
    -david

    Hi Alex,
    From ACE perspective, it doesn't make differences if you are using certificates issued by your local or a "well known" CA. Moreover, if not mistaken, you have to configure authentication group whatever you are doing client or server authentication.
    http://www.cisco.com/en/US/partner/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA4_1_0/configuration/ssl/guide/certkeys.html#wp1043643
    Thanks,
    Olivier

  • Update Windows Root Certificates in Windows 2008 R2 Disconnected Environment using WSUS

    Hi all, I need to update the root certs on all my WIndows 2008 R2 servers. They have no internet connectvity. I am aware of the issue described by
    KB931125 but I am not affected by it. My issue is that I would like the 2008R2 servers to update the roots certs form my WSUS servers. Is this possible?

    I would suggest that you identify the few individual root certificates that you need, and import them individually to those servers where they are needed.
    It is NOT possible to update root certificates from a WSUS server, except in the case of workstations that are being configured to install KB931125.
    Do NOT install KB931125 to a server operating system.
    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Remove unwanted issues Root certificates

    Do some typos in my AIA and CDP ldap paths I had to re-issue a new certificate from my offline root three times.  So within the trusted root certificate authority on all my clients their are three root certificates which have been downloaded from
    the domain.  Two of the certificates have been superseded by the newest issued root certificate and is not needed. 
    Is there anyway to clean up these old root certificates? I want it so that newly joined domain machines only download the newest root certificate into the machine's root certificate authority.
    Thanks for everyone's help.
    Joel

    For an offline CA these certificates have been distributed either:
    by downloading them from Active Directory's config. container - if you have published them before with
    certutil -dspublish -f [Your Root CA].crt RootCA
    or via Group Policies - in this cases you have added them to a computer GPO before.
    In either case you could remove the CA certificates from clients by deleting them from the respective "central AD store" before:
    from AD config. container: Use pkiview.msc, right-click the top node,
    Manage AD Containers, Certification Authorities. View all three certificates and delete the two older ones. You need Enterprise Admins rights for this unless permissions have been delegated.
    from the GPO:
    Computer Configuration/Windows Settings/Security Settings/Public Key Policies/Trusted Root Certification Authorities
    Having deleted the CA certificates run gpupdate /force at the clients or wait (also in case of 1. the download is triggered by GPO refresh).
    Edit: But one thing that strikes me odd: A Root CA certificate should not contain any AIA or CDP URLs - so does your question really refer to the Root CA certificate itself or to a subordinate CA certificate signed by the Root CA?
    In case you mean three subordinate CA certificates distributed to the Intermediate CA store you could delete them from the AD AIA store with pkiview.msc as well.
    Elke

  • The affects of removing a certficate template from a Certificate Authority

    I have inherited what I am beginning to believe is a poorly designed PKI Infrastructure. I have 1 root CA and 2 Issuing CAs all 2008 R2. My root certificate authority is expiring in about 2 months so I am planning to renew it and the Subordinate CAs soon.
    I see that the root CA has issued a lot of certificates and that many templates are available. The root is not offline. (I know not best practice).
    I would like to remove these templates from the Root CA and allow the subordinates to do all the issuing. If I do this before I renew the Root CA then all the certs currently issued will expire in 2 months and not be renewed on the Root CA.
    My questions are:
    In the scenario above will the certificates originally issued by the Root CA be renewed on the Subordinate CAs?
    Most of these certs seem to be auto enrolled. Will Auto Enrollment know to go to the Subordinate CA from now on?
    Are there any other concerns with taking this action that I should be aware of?
    Most of the certificate templates on the Root CA are default templates and I believe are Auto Enrolled. (I haven’t manually issued certs for these templates)
    Basic EFS
    Computer (I know this one is auto enroll)
    Domain Controller

    First, you have to renew all CA certificates starting with root (down to hierarchy) before you proceed.
    > In the scenario above will the certificates originally issued by the Root CA be renewed on the Subordinate CAs?
    yes. Clients will use any enterprise CA that supports specified template.
    > Most of these certs seem to be auto enrolled. Will Auto Enrollment know to go to the Subordinate CA from now on?
    again, yes, see above.
    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new:
    PowerShell FCIV tool.

  • ISE Certificate Authority Certificate

    I'm confussed about the certificates:
    Some weeks ago a certificate was installed in the ISE to avoid the browser certificate error when the customer access the sponsor portal ...
    Now, the customer is requesting to authenticate the sponsor users through LDAPS ... I understand Active Directory or LDAP as External Identity Sources are not secure. So, in order to enable LDAPS we must check the Secure Atuthentication box in the LDAP configuration, but a ROOT CA must be chooseen also.
    I understand the ISE should validate the customer PKI in order to validate the user certificate ... Am I right?
    Do I need request the customer to provide me the "Certificate Authority Certificate" from its PKI ??
    Is it a file completely different to the certificate already loaded in the ISE ??
    With this certificate, would the ISE validate the user's computer certificate additional to user and password ??
    Would the user must use a computer with certificate in order to access the sponsor portal ??
    Thanks in advance.
    Regards
    Daniel Escalante.

    Please follow the "secure authentication tab" in the below table( highlighted)
    go to >LDAP Connection Settings
    Table lists the fields in the LDAP connection tab and their descriptions.
    Table :     LDAP Connection Tab 
    Option Description
    Enable Secondary Server
    Check this option to enable the secondary LDAP server to be used as a  backup in the event that the primary LDAP server fails. If you check  this check box, you must enter configuration parameters for the  secondary LDAP server.
    Primary and Secondary Servers
    Hostname/IP
    (Required) Enter the IP address or DNS name of the machine that is  running the LDAP software. The hostname can contain from 1 to 256  characters or a valid IP address expressed as a string. The only valid  characters for hostnames are alphanumeric characters (a to z, A to Z, 0  to 9), the dot (.), and the hyphen (-).
    Port
    (Required) Enter the TCP/IP port number on which the LDAP server is  listening. Valid values are from 1 to 65,535. The default is 389, as  stated in the LDAP specification. If you do not know the port number,  you can find this information from the LDAP server administrator.
    Access
    (Required) Anonymous Access—Click to ensure that searches on the LDAP  directory occur anonymously. The server does not distinguish who the  client is and will allow the client read access to any data that is  configured as accessible to any unauthenticated client. In the absence  of a specific policy permitting authentication information to be sent to  a server, a client should use an anonymous connection.
    Authenticated Access—Click to ensure that searches on the LDAP directory  occur with administrative credentials. If so, enter information for the  Admin DN and Password fields.
    Admin DN
    Enter the DN of the administrator. The Admin DN is the LDAP account that  permits searching of all required users under the User Directory  Subtree and permits searching groups. If the administrator specified  does not have permission to see the group name attribute in searches,  group mapping fails for users who are authenticated by that LDAP.
    Password
    Enter the LDAP administrator account password.
    Secure Authentication
    Click to use SSL to encrypt communication between Cisco ISE and the  primary LDAP server. Verify that the Port field contains the port number  used for SSL on the LDAP server. If you enable this option, you must  choose a root CA.
    Root CA
    Choose a trusted root certificate authority from the drop-down list box  to enable secure authentication with a certificate.
    See the "Certificate Authority  Certificates" section on page 12-17 and "Adding a Certificate  Authority Certificate" section on page 12-19 for information  on CA certificates.
    Server Timeout
    Enter the number of seconds that Cisco ISE waits for a response from the  primary LDAP server before determining that the connection or  authentication with that server has failed. Valid values are 1 to 300.  The default is 10.
    Max. Admin Connections
    Enter the maximum number of concurrent connections (greater than 0) with  LDAP administrator account permissions that can run for a specific LDAP  configuration. These connections are used to search the directory for  users and groups under the User Directory Subtree and the Group  Directory Subtree. Valid values are 1 to 99. The default is 20.
    Test Bind to Server
    Click to test and ensure that the LDAP server details and credentials  can successfully bind. If the test fails, edit your LDAP server details  and retest.

  • UCS Manager and using Microsoft Certificate Authority

    Has anybody gone through the process of setting up UCS Manager with a certificate issued from a Microsoft Certificate Authority?  If so I would appreciate some assistance.  I was able to successfully create a request and have generated the certificate, but I see no way of being able to put the request and the certificate chain back into UCS Manager.

    First you have to create a trusted point (under the Admin Tab -> Key Management). In the new trusted point, paste the public cert in base64 format of your root certificate authority. If you have a subordinate CA that's issuing then add that CA's cert too. If you have a whole tree of CAs, then you need to create a trusted point with all the CAs in the chain from the issueing CA up to the root. Paste one cert after the other, in order, up the chain, all in the same trusted point. If they're not in the right order or if you're missing the root, then the TP won't accept the cert.
    Once you have a trusted point you can accept the certificate you generated. In the KeyRing you used to generate the request, choose the new Trusted Point, and paste the new certificate in Base64 format into the Certificate field.
    Once that's done, you can go to Communication Management -> Communication Services, and for the HTTPS protocol, choose the new Key Ring. It might not take effect immediately, but after a few minutes your UCSM web site should start responding with the new certificate.
    I hope that helps.
    Note: There's a bug in UCS currently issue number CSCth62582. If your fabric interconnects fail over, the SSL cert will revert to the default self signed cert. You have to go back into Communication services and set it to default, save, then set it back to the new Key Ring.  

  • Go Daddy UCC Certificate: "ExRCA can only validate the certificate chain using the Root Certificate Update functionality from Windows Update"

    Hello,
    I have this issue regarding certificate chains while performing Outlook Anywhere connectivity test
    by Microsoft Remote Connectivity Analyzer:
    "ExRCA can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled."
    Note: even if I got the error, Outlook Anywhere and
    ActiveSync services work fine.
    Environment:
    - Exchange 2007 with SP3
    - Go Daddy Multiple Domains UCC certificate (up to 5 Subject Alternative Names)
    I already read and followed instructions on this TechNet post
    Can I safely ignore this warning about the SSL cert? Using GoDaddy UCC cert but it is a little bit different by this case.
    So after an investigation I understand the issue above is related to SSL certificate
    Certification Path (see screenshots below).
    NO ERRORS on ExRCA checking
    Go Daddy Secure Certification Authority is under Intermediate Certification Authorities
    repository
    Go Daddy Class 2 Certification Authority is under Intermediate Certification Authorities
    repository
    Starfield Technologies (http://www.valicert.com)
    is under Trusted Root Certification Authorities repository
    ERROR on ExRCA checking
    Go Daddy Secure Certification Authority is under Intermediate Certification Authorities
    repository
    Go Daddy Class 2 Certification Authority is under Trusted Root Certification Authorities
    repository
    Can you add some useful information ?
    I'm opening a support ticket at Go Daddy; I hope they could me some positive feedbacks.
    Regards,
    Luca Fabbri
    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Strange I have a feeling the exrca tool can't validate the godaddy class2 root authority due some older compability and wants to use the older original root authority valicert owned godaddy. Or when the exrca tool is validating the root CA it only has the
    goaddy class2 root ca that was issued by valicert and not the standalone cert when doing the comparision. I sent the question to MS and will let you know when I hear back.
    You can get rid of it
    https://certs.godaddy.com/anonymous/repository.seam
    Download the cert
    ◦gd_cross_intermediate.crt
    Then import it into the trusted root cert authority on your CAS boxes. Then you need to delete the other godaddy class2 root authority. Make sure you see the one you imported both will be named goaddy class2 root authority but one will be issued by valicert.
    Re-run the test and it will go away, I also saw the error with my domain as well using godaddy and got rid of it by using the new cert authority.
    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

  • Certificate Authority root CA increased validity problem

    Dear all,
    I was successfully able to create in Certificate Services root CA for 20 years, issued a certificate and login using smartcard using the following procedure:
    1. I increased the CA lifetime to 20 years by using this link http://www.expta.com/2010/08/how-to-create-certificates-with-longer.html
    Created the file CAPolicy.inf in %SYSTEMROOT% with following content
    [Version]
    Signature=”$Windows NT$”
    [certsrv_server]
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=20
    2. Renew CA root using this guide  https://technet.microsoft.com/en-us/library/cc780374(v=ws.10).aspx
    Console Root -> Certification Authority -> select domain -> Right click -> All Tasks -> Renew CA certificate
    3. Delete from
    Console Root -> Certificates (local computer) -> Trusted Root Certification Authority -> Certificates the *WINSC-CA that has the previous lower validity, and from 
    Certificates (local
    computer) -> Personal, the *WINSC-CA that was lower validity
    4. I performed a reboot here
    5. Change in Console Root -> Certificate Templates -> Smartcard Logon Custom Template (my custom duplicate template) -> Properties -> Validity 10 years
    6. Change in registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>\ValidityPeriod
    to value 10 for 10 years.
    7. Request a new certificate from CA webpage http://ipofdomain/certsrv and let the webpage write it to smartcard (I was making
    sure there is no other certificate on the smartcard)
    8. Try to log in. At this point it should throw an erorr that smartcard logon is not supported for this account type. This
    is becuase we need to enroll it again for domain authentication
    9. Console Root -> Certificates (local Computer) -> Personal -> Right click -> All Tasks -> Request new Certificate
    -> Next -> Active Directory Enrollment -> Next -> Select Domain Controller Authentication -> Enroll -> Finish.
    Now you should be able to login using your smartcard and 10 years generated certificate.
    Though I have a
    problem at step 3, after CA server reboots the *WINSC-CA certificate with lower validity is restored automatically, but the certificates are generated for 10 years.
    What am I doing
    wrong ? How can I delete the lower validity root CA ?

    Hi,
    Thanks for your post.
    Did you try to restart the CertSrv service to check the result after you create and save the CAPolicy.inf file?
    Regards.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

  • Update for Root Certificates for Windows 7 [March 2014] (KB931125) - Expired on SCCM 2012 March 2014 SUG

    Hi all,
    The "Update for Root Certificates for Windows 7 [March 2014] (KB931125)" is Expired on SCCM 2012 March 2014 SUG. Is this a problem and is there going to be any fix for this which we can expect in the future?

    I don't have a 931125 for March 2014; however, I do have a November 2013 for 931125 which is still valid. Per the KB (http://support.microsoft.com/kb/931125) the November 2013 is the current and valid versions.
    931125 is an unusual update as they simply update it with a new version instead of creating a new KB that supersedes it. Now, why they expired the March 2014 version is unknown but they probably found an issue with it shortly after it was released.
    As a rule, you should always ensure that the search you use or criteria in your ADR excludes expired updates.
    So, to answer the question, no this isn't an issue.
    Jason | http://blog.configmgrftw.com

  • Unable to Install Root CA Certificate - Certificate cannot be verified up to a trusted certificate authority.

    Hi,
    I am trying to install CA root certificate on Windows 7, IE 9.
    Encounter error: "Untrusted Certificate".  "This certificate cannot be verified up to a trusted certificate authority."
    I have tried to install the certificate to Trusted Root Certificate Authorities->local computer and import was successful. BUT on IE->Internet Options->Certificate->Trusted Root Certificate Authorities, I am unable to find this root CA on
    the list.
    On mmc->Certificates->Trusted Root Certificate Authorities->certificates, I am able to view this root CA.
    I then restarted the IE and view the ssl site again but failed too, "Untrusted Certificate".
    Anyone, any idea ?
    Regards,
    Eye Gee

    Hi,
    If you install the certificate but then cannot see it please read the following KB article:
    You cannot view certificate information in Windows Internet Explorer 7 or in Certificate Manager after you successfully import a certificate on a Windows Vista-based computer(although it applies to Windows Vista)
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;932156
    This is also because of this: Microsoft Security Advisory: Update for minimum certificate key length
    http://support.microsoft.com/kb/2661254
    To get rid of the error, you can self-signed certificate for a secured website in Internet Explorer.
    To do this, follow these steps:
    1. In Explorer Options, add the URL to your trusted sites. Exit Explorer.
    2. In Windows Internet Explorer, click Continue to this website (not recommended).
     A red Address Bar and a certificate warning appear.
    3. Click the Certificate Error button to open the information window.
    4. Click View Certificates, and then click Install Certificate.
    5. On the warning message that appears, click Yes to install the certificate and place it in your trusted certificates authority.
    6. Exit Explorer then open the page again. Error should be gone.
    I also would like to suggest you refer to the link below to learn more about certificates:
    Certificate errors: FAQ
    http://windows.microsoft.com/en-HK/internet-explorer/certificate-errors-faq#ie=ie-11
    Understanding Certificate Revocation Checks
    http://blogs.msdn.com/b/ieinternals/archive/2011/04/07/enabling-certificate-revocation-check-failure-warnings-in-internet-explorer.aspx
    Hope it helps.
    Regards,
    Blair Deng
    Blair Deng
    TechNet Community Support

  • Windows 2012 root certification authority in a 2003 Domain/ Forest level

    Hello,
    We are currently on Windows 2003 Domain & Forest Functional Level. Our Root CA is also currently on Windows 2003 DC.
    If  we have to setup a new Root/Issuing CA ( not exporting the current 2003 CA cert) on Windows 2012 R2 servers,   is it then mandatory to first upgrade Domain & Forest levels to 2012 R2 ?  Can we have  a PKI infrastructure with
    Enterprise CA's on a Windows 2012 Platform but the Domain/Forest levels  still on 2003 level ?   i understand it will be good to have everything on 2012 R2 , but can a mix of 2003 domain level  and 2012 CA  work ?

    Hi,
    Look at below tread it might help:
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/fa8cac92-0f71-426c-ac95-e89e90e1c8d1/certificate-authority-and-forestdomain-functional-level?forum=winserversecurity
    Basically the answer is yes you can have  CA on 2012 R2 and DFL/FFL still on 2003.
    Regards,
    Calin

  • Windows Server 2008 R2 Standard "Certificate Authority Service" / Exchange Server 2010 EMC not starting and no AD connectivity for authentication.

    Hello,
    I am a new IT Manager at this company and need assistance big time. Their environment looks as follows:
    Server 1. Domain Controller Server (Windows Server 2008 R2 Standard) running active directory.
    Server 2. Email Server (Windows Server 2008 R2 Standard) running Exchange Server 2010 .
    * Note. No back ups to work with aside from whats mentioned below.
    DC had a virus infection causing a lot of issues on the shared network drives 2 days ago locking up all the files with a crypto ransom virus. Running Avast suppressed the infection. Had to recover the file shares which luckily had a back up. 
    The issue is that the Exchange Server 2 post this lost connectivity with the AD Server 1. Exchange Server 2 when launching EMC could not launch the console stating the following:
    "No Exchange servers are available in any Active Directory sites. You can’t connect to remote
    Powershell on a computer that only has the Management Tools role installed."
    Shortly after I found that it is possible the EMC launcher was corrupt and needed to be reinstalled following another blog post. I deleted the exchange management console.msc  per instructions only to discover I couldnt relaunch it because there was
    no way how. So I copied another msc file that happened to be on the DC Server 1  back to Exchange Server 2 and got it to launch again. 
    Another post said that it might be an issue with the Domain Account for the Computer, so to delete it in the AD Server 1 only to find that rejoining it from Exchange Server 2 using Computer>Properties> Chage Settings > Change is greyed out because
    it is using the Certificate Authority Service.
    I tried manually re-adding the computer in AD and modeling permissions after another server in group settings but no go. After this I was unable to login to the Exchange Server 2 with domain accounts but only local admin, receiving the following Alert:
    "The Trust Relationship between this workstation and primary domain failed."
    I tried running the Power Shell tools on Exchange Server 2 to rejoing and to reset passwords for domain accounts as noted in some other blogs but no luck as the Server 2 could not make the connection with Server1 or other errors it kept spitting out.
    I also during the investigation found the DNS settings were all altered on both the Server 1 and Server 2 which I luckily was able to change back to original because of inventorying it in the beginning when I started. 
    I need help figuring out if I need to rejoin the Exchange Server 2 manually by disabling the Certificate Authority Service (or removing the CA as listed here:
    https://social.technet.microsoft.com/Forums/exchange/en-US/fb23deab-0a12-410d-946c-517d5aea7fae/windows-server-2008-r2-with-certificate-authority-service-to-rejoin-domain?forum=winserversecurity
    and getting exchange server to launch again. (Mind you I am relatively fresh to server managing) Please help E-Mail has been down for a whole day now!
    Marty

    I recommend that you open a ticket with Microsoft Support before you break things more.
    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

  • Certificate Authority is not being seen by windows server 2003 machines

    Good Afternoon,
    We recently installed a certificate authority using windows server 2008 r2. There was an old certificate authority that had went bad and the role could not be uninstalled on the bad server. The new certificate authority works with windows 2008 machines but
    does not work with server 2003 machines. Mainly trying to get the domain controller certificate. At first it was stating that the rpc was unavailable for the CA. I tried to delete the remnants under the sites and services role of the old server. The error
    now it states that it can not find a certificate authority. As stated above the newer machines (Server 2008)  can see the certificate authority and request certificates but older machines cant. Any assistance on what to do next will be greatly appreciated.
    Attached is the error I receive when trying to request a certificate through the CA mmc.
    dmg

    It is possible to change the hash algorithm a CA uses  to support XP and 2003 "out of the box" without the hotfix.
    But it would be better to have two CAs in parallel - one using a more modern algorithm and a CA supporting a "legacy" algorithm - and the latter should only be used as long as there are clients that aren't able to validate the other algorithms.
    On the CA, start regedit and locate the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\<Your CA>\CSP
    I am assuming that the Software CNG provider is used with SHA256 or higher (not with SHA1).
    Change CNGHashAlgorithm to SHA1 and restart the CA service.
    The setting can be reverted by changing the value back. All certificates and all CRLs signed by this CA will use the new hash algorithm after the restart.

  • Certificate Authority Windows 2008 to 2012 R2 - Clean up and Migration

    Hello,
        I'm currently dealing with the following scenario:
    1. I've inherited the current infrastructure setup and the plan is to clean things up and setup a new certificate infrastructure using Windows 2012 R2.
    2. The current setup:
        a. Domain Controller, Windows 2008 R2, is/was a Certificate Authority.  It hasn't issued any new certificates (based on the information in Certificate Effective Date) for quite some time.  It also has an expired certificate for
    itself - issued by the domain's issuing CA - and attempts to renew it via MMC give a "Server execution failed" and STATUS: Failed when looking in Certificate enrollment for Domain Controller.  We'll call the server, DC1.
        b. Certificate Authority Server, we'll call it CERT1.  When booting up the machine and/or attempting to restart certificate services on the server, the following errors are in the event log:
    EVENT 7024: Description: The Active Directory Certificate Services service terminated with service-specific error %%-2146885613.
    EVENT 100: Active Directory Certificate Services did not start: Could not load or verify the current CA certificate.  Domainlocal Issuing CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013
    (-2146885613).
    EVENT 48: Description: Revocation status for a certificate in the chain for CA certificate 0 for Domain.local Issuing CA could not be verified because a server is currently unavailable.  The revocation function was unable to check revocation because
    the revocation server was offline. 0x80092013 (-2146885613).
    Note:  The server's computer certificate has expired and it was issued by the Domain Controller mentioned in point A.  Attempts to renew it fail.
    (The issue on CERT1 is like the one mentioned in this article: https://support.microsoft.com/kb/825061?wa=wsignin1.0  however an upgrade wasn't done and it's not old versions of Windows.)
    c. There is a certificate authority machine - part of what was created for a PKI infrastructure - that was kept shutdown.  I've powered it up and the machine is not part of the domain.
    Any thoughts or feedback on easily repairing the current situation so that I can upgrade everything to a new Windows 2012 R2 Certificate infrastructure would be appreciated.
    Thanks!

    Hi Vadims,
        Basically using certificates in the following manner:
    1. User / Computer enrollment in the AD domain.
    2. Any hardware / web services (internal) that need a certificates.  This is usually hardware that has some form of GUI that is accessed via URL, printers accessed via URL and/or that communicate via LDAP to AD, internal UC (Lync is an example), that
    sort of thing.
        A number of machines currently show certificate errors (ie.. certificate has expired) however that hasn't stopped things from working just functioning differently.  I'm going already on the assumption that if I remove the entire CA
    infrastructure and re-install a new one and have everything point to that new CA server that I should be ok but I'm not 100% certain hence why I asked on this forum.
    Also, you're correct is that there is one more CA.  That CA was the server that was turned off/offline that I powered on.  It is not part of the AD domain that the domain controller and the other CA belong to.  (It is standalone.)  I'm
    currently patching the standalone CA since it's been off for what looks like almost 1.5 years. 

Maybe you are looking for