I dont want to launch the tool and do it, but want to do it programatically say moving the registry entry along with the file system or folder something like that so that i don't use tool such as certmgr. Ok will try the above steps you mentioned and then import it onto the destination machine wrt Certificates.
For IE 9. My source machine is XP with IE8. Office Office Exchange Server. Not an IT pro? Windows Client. Sign in. United States English. Ask a question. Quick access. Search related threads. Remove From My Forums. Answered by:. In a Windows Server network, cross-certification is the preferred method for restricting certificate usage between organizations. Certificate Trust Validation A process that determines if a certificate chains to a root CA certificate that is trusted by the actual security context.
Public Key Infrastructure PKI Provides an organization with the ability to securely exchange data using public key cryptography. The PKI provides validation of certificate-based credentials and ensures that the credentials are not revoked, corrupted, or modified. This hash is placed in the Authority Key Identifier AKI extension of all issued certificates to facilitate chain-building. The following sections outline the components used by the Windows operating system when performing certificate status checking.
These components include:. CryptoAPI provides services that enable application developers to add security to applications. It includes functionality for encoding to and decoding from ASN. The certificate processing functionality of CryptoAPI is implemented in crypt Both libraries provide a rich set of application programming interfaces APIs.
Since cryptography functionality in Windows is constantly improved, CryptoAPI is available in a number of different versions. The versions differ slightly in their certificate status checking functionality. Some support features like delta CRLs and others do not, as shown in Table 1. The update ensures consistent certificate path processing for Windows , Windows XP, and Windows Server computers on your network.
The update specifically changed the following aspects of certificate path processing for Windows computers. A certificate securely binds a public key to the entity that holds the corresponding private key. A certificate is commonly used for authentication and secure exchange of information on open networks, such as the Internet, extranets, and intranets.
Certificates are digitally signed by the issuing CA and can be issued for a user, a computer, or a service. A certificate is a collection of certificate attributes and extensions that can be stored as a file or is maintained in a certificate store. The set of fields in a certificate may vary depending on the certificate request and the certificate template that was used to issue the certificate.
Generally, it is the responsibility of a security-enabled application to interpret the content of a certificate or to use a sub-system like CryptoAPI to verify the status of a certificate. Fields in a certificate can be marked as critical or non-critical when the certificate request is created.
The CryptoAPI engine does not enforce critical extensions in certificates. The CryptoAPI engine and programming model puts the responsibility of parsing critical extensions on the calling application.
Therefore, an application must understand and enforce a critical extension when it evaluates a certificate. Note The default behavior of an application, as defined in RFC , should be to reject a certificate if the certificate contains a critical extension not understood by the application. It is still possible for an application to accept a certificate that contains a non-critical extension that is not understood by the application.
Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system, in the registry, or implemented as physical stores such as smart cards. Certificate stores are associated either with the computer object or they are owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores the same as user accounts.
A certificate store will often contain numerous certificates, possibly issued from a number of different CAs. A computer local system has read and write permissions to the personal certificate store that belongs to the computer. A user who owns certificate stores also has read and write permissions to their own personal store and read-only access to the certificate stores that are owned by the computer. The Certificates console display merges the two views, showing both the certificate stores that belong to the computer as part of the certificates node of the current user.
A user without local administrative permissions has no access to certificate stores that are owned by services.
Note Only members of the local Administrators group have the ability to manage certificate stores that are owned by the computer or a service. The advantage of sharing certificate stores between the computer and the user is to reduce the total number of certificates that have to be stored in all certificate stores on a computer. Certificate chains are formed by looking at certificates available in multiple certificate stores.
The certificate chaining engine must determine what scope of certificate stores to search when building certificate chains. The certificate stores may be viewed through the Certificates snap-in Certmgr. On a Windows —based computer, you must open an empty MMC console, and then open the Certificates snap-in focused on the Current User. Each of these certificate containers has physical sub-containers. These sub-containers maintain certificates according to their origin.
A user may have added certificates to his or her profile. The user may have downloaded certificates from Active Directory. The number of certificates per store is limited by the total registry size and performance.
Larger amounts of certificates within a store can result in performance problems because all certificates within the store are decoded into memory when the certificate store is opened. Note Microsoft has tested stores with certificates with no performance problems. When CryptoAPI needs to discover a certificate, it can use any store where the current security context has read permissions. In addition to the default stores, the certificate chaining engine can be configured to use different stores.
While the Trusted Root Certification Authorities store is the only store that can contain trusted root certificates, an application can use other stores, such as restricted root, restricted trust, restricted other, and additional stores to further restrict the set of root certificates considered trusted.
Also, an application can create its own store for certificate storage or even call additional revocation providers registered with CryptoAPI. In addition to which certificate stores are searched during a chain validation call, the certificate chaining engine can also be configured with the following parameters programmatically. Certificate management tools distinguish between the physical structure of certificate stores and their logical abstraction.
The logical abstraction, which simplifies the physical structure, was implemented to group certificates by function or purpose and provided a simpler way to understand certificate stores. Unfortunately, today, different certificate tools exist to maintain certificate stores. Users may prefer one tool over the other to maintain their certificates. The following list briefly explains the tools and their capabilities. Note It is not recommended to modify or manage the contents of a certificate store by using the Registry Editor regedt If certificates are written to certificate stores, the physical structure is more important than the logical structure.
The system expects certificates at predefined physical locations. Even if a certificate seems to be at the right logical position, it might not be at the right physical location. Since the logical view forms a union of both stores, the users might not recognize the actual physical location of a certificate. Each certificate store can physically have a number of subcontainers. The Certificates console knows the following physical store names.
The stores are invisible by default and show up only if the physical certificate store view has been turned on. Generally, it is recommended to know the physical structure of certificate stores because it enables the administrator to maintain certificates at the right physical location. Different tools use different names for the same certificate store. Table 2 shows the names that are used by these tools. Note If you are importing a certificate along with a private key a.
If it is an end-entity certificate for which you do not have a private key, it will go in the Other People store. If it is a CA certificate and not a root self-signed , it will go to the Intermediate Certification Authorities store.
If it is a self-signed certificate, it will go to the Trusted Root store. In all cases, a user can change the described default behavior by designating a specific store when running the Certificate Import wizard.
A certificate store is a location where related certificates are stored. The root store is the certificate store used to establish trust when certificates are validated. Microsoft ships a set of root certificates built into the root store from commercial CA's like Verisign and Thawte.
There are over such built-in root certificates. Under this management model, the customer accepts the default choice of root certificates provided by Microsoft. For Windows and earlier versions, a patch is available for download from the Windows Update Web site. Customers can choose to customize the list of trusted root certificates trusted on a single machine.
On a single machine, the root certificates can be added to either the local machine store or to the current user store. If Administrators want to customize the list of root certificates trusted by machines in their domains, they can distribute additional root certificates through Group Policy objects that are linked to domains or organizational units OUs.
When trusted root certificates are defined in a GPO, they are defined in the Computer Configuration container shown in Figure 3.
In addition to defining which root authorities are trusted in the domain or OU where the GPO is linked, you can also define whether the plus commercial CAs that ship in the box are trusted by computers where the GPO is applied. To prevent trust of the third-party root CAs, ensure that "Client computers can trust the following certificate stores" option is set to "Enterprise Root Certification Authorities" as shown in Figure 4.
If Administrators want to customize the list of root certificates trusted by all machines in their forest, it is recommended to publish the root certificates in Active Directory in the Enterprise Trust Store, When a root certificate is published in Active Directory by using the Certutil.
Note The actual command used to publish the root certificate in Active Directory is. Windows , Windows XP, and Windows Server domain member computers will automatically download these certificates using the built-in autoenrollment service. A CA that is included in the NTAuth store is considered trusted for issuing authentication certificates.
This provides a form of mutual authentication between the user and the domain controller, ensuring that the certificates were issued by a trusted source. A CRL is a file, created and signed by a CA, which contains serial numbers of certificates that have been issued by that CA and are revoked. In addition to the serial number for the revoked certificates, the CRL also contains the revocation reason for each certificate and the time the certificate was revoked.
Base CRLs keep a complete list of revoked certificates while delta CRLs maintain only those certificates that have been revoked since the last publication of a base CRL. These alternative revocation providers are possible because CAPI is built on a pluggable revocation provider model. It is known as the NextPublish extension. The Windows Server CA does not implement this extension, but has limited support on Windows clients with MS installed, Windows XP clients, and Windows Server clients when performing chain validation.
If the IssuingDistributionPoint extension is marked as a critical extension, validation of a certificate chain with the IDP extension will fail. If the IssuingDistributionPoint is marked as a non-critical extension, the contents of the IssuingDistributionPoint are ignored.
You would have to write code to add it to the request, write a custom policy module, or use certutil —setextension on a pending request. The process of revocation invalidates a certificate before its end validity date using one of the CRL reason codes. Note Windows does not support partitioning CRLs by reason code as either a server or a client.
When a certificate is revoked, it is possible for a certificate issuer to specify why the action was taken. This is done by specifying a revocation reason; these reasons are defined by RFC and include the following:. Windows computers with the MS patch applied, Windows XP, and Windows Server support both binary and base64—encoded formats. Thus, certificate revocation verification is not performed for expired certificates.
If a CA publishes a complete base CRL frequently, clients are quickly aware of a newly revoked certificate. However, this can cause higher amounts of network traffic due to the more frequent downloading of the updated CRL to all clients. If a CA publishes CRLs less often, this reduces the amount of network traffic, but increases the latency before a client is aware of a newly revoked certificate. Remember that clients cache CRLs locally until they are expired.
Because of their assumed smaller size, delta CRLs can be published at shorter intervals than base CRLs to increase the confidence in the certificates being validated without the resource burden of frequent base CRL publication.
Note Although delta CRLs can be published at shorter intervals, you must consider network latency when determining the delta CRL publication schedule. For example, if it takes eight hours for changes in the Configuration naming context of Active Directory to fully replicate to all domain controllers, and you plan to include CDP URLs that reference Active Directory, you cannot publish delta CRLs more frequently than every eight hours.
At time t 1 , the certificate Cert5 is revoked. At time t 3 , the certificate Cert7 is revoked. The delta CRL process is very similar to a differential backup strategy. As a differential backup will include all files that have changed since the last full backup, a delta CRL contains all revoked certificates since the last base CRL was issued.
The extensions include:. These changes include:. When you add Certificate Services on a Windows server and configure a CA, a certificate database is created. The database can contain:. The enrollment process automatically creates the necessary entries.
Microsoft Certificate Services copies issued certificates and pending or rejected requests to local computers and devices.
The storage location is called the certificate store and consists of the following logical stores. You cannot use the Certificate Enrollment API to specify or retrieve store properties or copy certificates to specific stores.
0コメント