Open the snap-in. Select the root CA, right-click and choose properties. You will get a couple of tabsheets :. Open the "details" tabsheet and look for the "Key Usage" and "Basic Constraints" fields, you should get this :. Policy Module : This tabsheet allows you to define whether certificate requests should be processed automatically or manually. On the root CA, set this to "Set the certificate request status to pending….
Exit module : This allows you to define whether you want to publish certificates to the filesystem or not. The default setting is Yes. Leave this setting to Yes. On the root CA, only allow publication to local file system and http. You need the local filesystem entry so the crl file is put on the local filesystem when a new crl is created. Storage : this indicates where the CA will store its data. For a standalone root CA, this will be a location on a disk. Certificate Managers : This setting allows you to delegate access to some specific templates.
You will be able to further refine security on specific templates on your Enterprise CA. For the root CA, I would strongly recommend to limit the number of people who will have access to this CA. Open the file which should still be empty and look at the "Issuing Distribution Point Name". Verify that it contains the value that you had expected. Look at the Effective Date and Next Update dates.
If you have set the CRL Period to 1 year, then the values in this field should reflect that setting. Windows supports 3 Certificate Template versions : Version 1, 2 and 3. When the schema change has complete, enable replication again. Verify that replication occurs and works fine. The new version should be v Note : These schema changes are not required in order to set up a Windows Enterprise CA in your forest.
The updates will only enable the use of v3 templates. And if you ever want to start using v3 templates, you can still update the schema afterwards. The initial setup process of the Issuing CA looks very similar to the procedure used to set up the root CA. Again, you can start with building a CAPolicy.
Add the computer object that is going to host the CA into the Pre-Windows compatible access group, and into the "Cert Publishers" Domain local groups in each domain. Log in as member of the Enterprise Admins and local administrators on the server that is going to host the Issuing CA. Read and accept the note about not being able to change the hostname or domain membership afterwards.
You will be prompted to access the additional roles that need to be installed because you have selected the "Certification Authority Web Enrollment". On the next screen, select "Enterprise". If you are not an Enterprise Admin, you will not be able to select "Enterprise".
Certificate request to parent : select to save the request to a file. Save the certificate request somewhere on your harddrive, so you can copy it to the root CA and get it signed. Define the database and log location e. Open the Certificate Authority mmc on the root CA.
Select the request file. Open the "Pending Requests" view, refresh and verify that you can see the Pending Request. Because you have selected to put all requests in pending state until administrator issues the request, the request will just stay in the "Pending Requests" view until you manually Issue the request. Simply right-click on the pending request and choose "Issue". Now we need to export this certificate so we can install it on the Issuing CA.
Open the certificate, go to the Details tabsheet and click "Copy to file". Click "next" on the Welcome screen. Select P7B format, make sure to select "Include all certificates in the certification path if possible".
Before installing this signed request, it is important to verify that the CDP website is active and works as designed. Select the signed certificate the file that was copied back from the root CA. You can now start the Issuing Certificate Authority by pressing the "start" button. Go to the Policy Module tabsheet and set the Request handling to "Follow the settings in the certificate template".
I recommend verifying whether all CRL settings are set correct before creating any certificates. Suppose you want to set the CRL to 1 week, with 2 days of Grace period, and set the CRL Delta to 1 day and finally, you want to set the maximum validity period for any certificate to 2 years, then use the following commands :. You will have to write a script to copy the crl files and crt aia file to the webserver s in order to make sure the CDP content is up to date.
Before creating certificates, you should use the pkiview. At lot of work has been done already, but we are still not ready to issue any certificate yet. First, we need to determine which templates we are going to allow, and who will be allowed to use those templates.
If one or more of the default Templates are installed, but just not enabled visible in the view , then you can enable that Template by running. The default Templates are v1 templates. As a result, when running a Windows server or standard edition, you only hace access to v1 templates.
The Directory Email Replication template is a v2 template. These default templates cannot be fully modified e. I strongly recommend creating new templates and then deploying these templates to the CA. You can create a new template by right-clicking the Certificate Templates view, and choose "Manage". You will now get the list with all available templates.
Select one of the templates, right-click and choose "Duplicate Template". The first thing that you will be asked to do is to select the Template version. Even if you have not updated the Schema to , you will still get the option to create a Windows Server , Enterprise Edition template. You can modify and save the template, but if you have not updated the schema, this template will NOT work.
You can now change all of the templates parameters. In the Template Name, I recommend not to use any strange characters or spaces. Otherwise, you would disable all of the existing enabled templates, and only enable the WebServerInternal1Y template. The template is the place where you can set the security for this template. You can basically state who can use this template to request certificates, you can determine who can manage this template etc.
Before changing the security or any other parameter , disable the template, make the changes, and then enable it again. You can then grant the "Read and Enroll" permission to a group of users in order to allow certain users to generate a certificate request.
If security has been set, you can enable the template again using the certutil command see above. Depending on your needs, you may want to enable AUthentication on the Web Enrollment website.
But in any case, I would recommend you to enable SSL on the website. Otherwise, you may not be able to properly request certificates. But if you want to fix this, you need to request a certificate from this Issuing CA and install it on the webserver…. A quick cli command to list all certificates that will expire in a given number of days Example : list all certificates that will expire in less than one year. If you want to know which certificate was enrolled using autoenrollment and may be renewed automatically based upon your template settings, and which ones will required manual intervention :.
The first command will list the Requests, the second command will indicate the Process used to enroll the certificate. If you put those 2 outputs next to each other, you can easily build a list of certificates that will require manual renewal. Of course, you can limit the scope of this command using the -restrict parameter as well. Processes including "CertEnrollCtrl. Processed including "inetmgr. As part of your daily operations, you must back up the CA.
YOu can only backup the private key by right clicking the CA and selecting "Backup". The nice thing is that you only need to do this once in the lifetime of the certificate. As long as you keep the key in a safe place, you should be fine. If you want to backup the CA database, then you can use a certutil command in a scheduled task script. The only requirement for the script to work is that the target directory is empty. If you ever need to restore the CA, you can simply build a new server with exact the same hostname.
During the setup of the CA , you can select to restore the CA from a backup and feed it your backup key and backup database. There are a couple of ways to deploy the root CA certificate into the Trusted Root Certificate Authorities store on your computers. If the computers are part of the domain, you can use a Group Policy to deploy the root CA certificate.
TechNet Community Support. To much automation makes it sometimes hard to understand what is really going on. I read this article but am a bit confused: why should I "choose generate domain certificate" if I want to bind ssl to the RootCA certificate that already exists??? If memory serves, the root CA certificate covers 'All issuance policies' and 'All application policies' not server authentication.
The more things that sit under a compromised certificate, the more your infrastructure is compromised, and the more pain it is when you have to revoke. Web servers, even internal only ones, are always one of the riskier components of your infrastructure.
Office Office Exchange Server. Not an IT pro? Windows Server TechCenter. Sign in. United States English. Ask a question.
Quick access. Search related threads. Information about these two types of authority : - For example, Google has created a subordinate certification authority because "GeoTrust" has sign the certificate of his authority.
And because that the certificate "Equifax Secure CA" is present in the list of trusted authorities on Windows, the certification authority of Google is thus validates and his certificates too.
This type of CA is interesting for an intranet preferably with an Active Directory but is not recommended for public access. Because our authority is not in the trusted certificate authorities by default, people around the world would see a warning about our certificates. If you want to use your certificates for a public website, you should buy your certificates separately or create a secondary authority as Google. The second option allows you to choose the private key from an old installation of your CA and you will ensure the continuity of certificates issued prior to the new installation.
When you access a website secured with your certificates is the common name that will be displayed because it's the real name of the authority.
Specify a validity period for the certificate of your CA. Note : As shown in this image, the validity period set for the authority's certificate must exceed the validity period of the certificates she will emit. To distribute our root certificate to clients of the Active Directory, we will need our root certificate. To export it, go to the bottom corner left to go to the touch interface and type "mmc". By going to "Certificates The certificates we generate will be considered as valid by our server only.
Close the console and click "Yes" to save it. It will save you time when you want to manage your certificates. To manage the certificate templates, return to the touch interface and click on "Certification Authority". Note : For Windows Server R2, you must first click the arrow at the bottom left to find this shortcut. Then, go to the "Security" tab and change the permissions of "Authenticated Users" so that they can request certificates registrations.
Check the "Registration" and "Automatic Registration" boxes. Close the "Certsrv" window or Certification Authority and reopen it. Then, as you can see, the new model isn't displayed by default. Total or partial reproduction of this site is prohibited and constitutes an infringement punishable by articles L.
Index System admin Virtualization. Registration Password lost?
0コメント