Install Active Directory Certificate Services (AD CS)

If you have decided to run your own certificate authority, the Windows counterpart is the Active Directory Certificate Services (AD CS) role. The install itself is half a day’s work; the real difficulty hides in a few wizard screens where the decisions you make cannot be undone.

This guide shows which decisions those are and where they appear, in order. This article is part of the Active Directory guide and assumes you have already decided to build an internal CA rather than use a public one or a self-signed certificate. Here we assume that decision is behind you.

AD CS is one of the server roles, and its install differs from the others in one respect: most of the decisions cannot be reversed. Screenshots and outputs come from the author’s lab domain (ad.sercebilisim.com); names and addresses are left exactly as they were captured.

If you know the prerequisites and want to go straight to the install, skip to the role installation.

Before You Install: Prerequisites and Rights

This guide assumes you have already stood up the Windows Server the role will run on. The operating-system install, disk layout and initial configuration are a separate subject. From here we take it that you have a working, networked server.

Three things must be settled before you start AD CS, because all three cannot be changed after installation, or are very expensive to change.

The Machine Name and IP Are Fixed Before Install

The server’s name, static IP and domain membership must be finished before AD CS is installed. The reason is not cosmetic: once the CA is installed, if the server is renamed, every certificate that CA issued becomes invalid. To rename it you would have to remove the CA, rename the machine, reinstall the CA with the same keys, and fix the registry by hand.

The same reasoning is why you do not install the CA on a domain controller: that is the machine whose name and role are most likely to change over time.

Domain Admin Is Not Enough for an Enterprise CA

This is where most of the time is lost, and the wizard never tells you why. To install an Enterprise CA you must be a member of the Enterprise Admins group; Domain Admins membership is not enough.

The reason is architectural: an Enterprise CA writes itself into the forest’s Configuration partition, which is shared across the whole forest rather than a single domain, and writing there is a forest-level right.

If the right is missing, the wizard does not error. It simply greys out the Enterprise CA option and leaves you only Standalone CA. A Standalone CA installs too, but it writes nothing to Active Directory: no templates, no autoenrollment, and clients can’t find the CA. In other words you would quietly build the wrong thing.

Verify your rights before the install. On the server you’ll build, signed in with the account that will run the install:

whoami /groups

Look for the Enterprise Admins line in the output. Do this check with the signed-in account itself, not a directory query: Get-ADUser -Properties MemberOf returns only direct memberships, whereas in most organisations the right comes through a second group nested inside an admin group. whoami /groups shows what the logon token actually carries, which is what the wizard will see.

If the line is missing, either sign in with an account in that group, or add your account to it for the duration of the install and remove it when you’re done. Enterprise Admins is the forest’s highest right and should not sit permanently on a day-to-day account. If you were just added to the group, sign out and back in; the token is built at logon and is not updated afterwards.

Decide the CA Name Rules in Advance

The CA name is embedded in the certificates and cannot be changed after install. Three rules:

• Do not use the server’s fully qualified domain name (FQDN). Anyone who obtains a certificate would learn the CA’s FQDN.
• Do not make it the same as the computer name.
• Avoid special characters such as underscores. Some network devices cannot enrol if the CA name contains a special character.

Installing the AD CS Role: A Two-Stage Process

The most confusing thing about AD CS is that the install does not finish in a single wizard. There are two separate stages, and most of what you’re looking for is in the second.

Stage one, Add Roles and Features: only puts the files on disk. It does not ask you for a CA name, type or validity period. On the Role Services screen you tick only Certification Authority; Web Enrollment, NDES and Online Responder can be added later without reinstalling the CA.

Stage two, Configure Active Directory Certificate Services: where the real decisions are made. When stage one finishes, a yellow warning flag appears in Server Manager, and you enter this wizard from there. Everything irreversible is here.

I saw again how sneaky this split is while preparing this article. I was working through the install taking notes step by step, and I had a list of what to choose on which screen: Setup Type, CA Type, CA Name, Validity Period. I opened the wizard, looked at the step list on the left, and there were only five lines: Credentials, Role Services, Confirmation, Progress, Results. None of the screens I was looking for were there.

For a moment I wondered whether I’d started from the wrong place. I hadn’t. Those screens weren’t in the list because they aren’t added until you tick the box on the Role Services step. The moment I ticked it and moved on, the left side grew and the seven screens I was after appeared.

I’ve worked with consoles like this for fifteen years and it still made me pause. You may pause too, so I’m writing it down: if the list looks short, you haven’t missed anything, you just haven’t ticked the box yet.

The CA Configuration Wizard: Screen by Screen

The second stage is ten screens, and four of them carry an irreversible decision. We go in order.

1. Credentials. Shows which account will run the configuration. This account must be a member of Enterprise Admins; if not, use Change... to switch to one that is. Rushing past this screen means coming back three screens later because of a greyed-out option.
2. Role Services. Tick the Certification Authority box. The other five services in the list (Web Enrollment, Online Responder, NDES and two Enrollment Web Services) appear greyed out because they aren’t installed; they can be added as roles later and configured from here.
3. Setup Type. Choose Enterprise CA. This binds the CA to Active Directory: the root certificate is written to the directory, templates become available, and domain-member machines find the CA on their own. Standalone CA is for environments without Active Directory; choosing it when a domain exists shuts down half of what you’re building. If Enterprise CA is greyed out, the account on step 1 is not a member of Enterprise Admins.
4. CA Type. For your first CA choose Root CA. Subordinate CA is used when you build a second tier under a root that already exists.
5. Private Key. Choose Create a new private key. The other option (Use existing private key) is for bringing a crashed CA back with the same keys.
6. Cryptography for CA. Leave the defaults: provider RSA#Microsoft Software Key Storage Provider, key length 2048, hash algorithm SHA256. Lengthening the key improves security but can break compatibility with older devices and applications. Do not tick the Allow administrator interaction when the private key is accessed by the CA box at the bottom; the reason is below.
7. CA Name. Type the name you settled on. The name the wizard suggests usually contains the computer name; change it if it doesn’t follow the naming rules above. This name cannot be changed later.
8. Validity Period. The default is 5 years. This is the root certificate’s own lifetime, and it has two consequences: the CA cannot issue a certificate that outlives its own, and by common practice the root certificate is renewed at half its lifetime. So a 5-year root puts the renewal on the calendar at year 2.5. In a lab or small-business scale, 10 years is a reasonable middle ground. The wizard calculates the expiry date from the number you type and shows it on screen (the CA expiration Date line); the date you’d put on the calendar is already there. When you change the value you’ll see the date update too, which is a good checkpoint.
9. CA Database. The location of the database and log files. The default C:\Windows\System32\CertLog is fine. If you choose another location, tighten the permissions on those folders by hand.
10. Confirmation. The summary screen. Configure applies the configuration, then the Progress and Results screens follow. On Results, the Certification Authority line should read Configuration succeeded.

Before You Click Configure: Check the Summary

The Confirmation screen gathers every decision you made into one list and is the last checkpoint before the point of no return. In our lab install the screen showed this:

Active Directory Certificate Services
  Certification Authority
    CA Type:                            Enterprise Root
    Cryptographic provider:             RSA#Microsoft Software Key Storage Provider
    Hash Algorithm:                     SHA256
    Key Length:                         2048
    Allow Administrator Interaction:    Disabled
    Certificate Validity Period:        10.08.2036 01:55:00
    Distinguished Name:                 CN=SerceBilisim-Lab-Root-CA,DC=ad,DC=sercebilisim,DC=com
    Certificate Database Location:      C:\WINDOWS\system32\CertLog
    Certificate Database Log Location:  C:\WINDOWS\system32\CertLog

The lab server’s locale prints dates day-first, so 10.08.2036 is 10 August 2036, not August 10th read the American way. Check four lines against your own screen, because all four are unfixable afterwards:

1. CA Type: Enterprise Root. If it reads Standalone, go back; nothing will be written to Active Directory.
2. Allow Administrator Interaction: Disabled. If it’s Enabled, autoenrollment won’t run.
3. The common name in Distinguished Name follows the naming rules: not the server’s FQDN, not the same as the computer name.
4. Is the Certificate Validity Period date the year you expected? That date is shown already calculated, and it’s the date you’d put on the calendar.

What Does the “Allow administrator interaction” Box Do?

This box on the Cryptography screen requires a human to approve every signature the CA makes. The CA’s private key is used only when signing certificates and the revocation list; with the box ticked, each of those accesses shows the user an authentication prompt from the crypto provider.

Its real home is installs with a hardware security module (HSM): the key lives in hardware and asks for a PIN on every operation.

On an online enterprise CA you leave it unticked. The reason is how autoenrollment works: when a server requests a certificate, the CA has to sign it without human intervention. With the box ticked, every request waits for someone to go to the CA console and approve it; autoenrollment effectively stops and the revocation list stops refreshing too.

The one scenario where it makes sense is an offline root CA: a CA opened only a few times a year to sign a subordinate CA certificate and a CRL, where a deliberate human gate at signing time is exactly what you want.

The Four Irreversible Decisions

A seal is engraved once. The name on it carries into every document stamped after; if you don’t like it, you don’t re-engrave the seal, you throw it out and have a new one made. The four decisions below are engraved at install time too: to “fix” one later is not to change a setting, it is to remove the CA and reinstall it.

Here are the ones to watch; changing any of them after install requires removing and reinstalling the CA:

The last two are also the ones the wizard shows you as you go. On the CA Name screen, the distinguished name builds itself below the common name as you type; that line is what goes into every certificate. On the Validity Period screen, the expiry date is calculated from the number you enter and shown on screen, which is exactly the date to put on the calendar.

AIA and CDP: Set Before the First Certificate

Don’t start issuing certificates the moment the install finishes. Two address settings must be done first, and the timing is critical.

AIA (Authority Information Access) tells clients where to download the CA’s own certificate; CDP (CRL Distribution Point) tells them where the revocation list is published. Both are embedded in every certificate that’s issued.

Here’s the catch: changing these addresses later affects only new certificates. Certificates already issued keep carrying the old address, and the only way to fix them is to reissue them all. A batch of certificates issued with the wrong configuration comes back months later as a “revocation check is hanging” fault.

The most common mistake on an internal CA is publishing the revocation list only at an address on the internal network: a laptop working off-site can’t reach that address, and validation hangs.

Where AIA and CDP Are Set

The setting is in the CA’s own properties: open certsrv.msc, right-click the CA name in the left tree, choose Properties, and go to the Extensions tab. The dropdown at the top selects which extension you’re editing.

• With CRL Distribution Point (CDP) selected, checkboxes appear at the bottom for each address in the list. The box that decides the address embedded in issued certificates is Include in the CDP extension of issued certificates. An unchecked address is published but not written into certificates.
• With Authority Information Access (AIA) selected, the counterpart is Include in the AIA extension of issued certificates.

By default both ldap:// and http:// addresses are defined. ldap:// works only for domain-member clients that can reach the directory; if you also have devices outside the office, you need a reachable http:// address.

I read what our own lab CA actually stamped, because “by default both addresses are defined” is not the same as “both were included.” On the certificate our CA issued to the domain controller, I read the AIA extension (OID 1.3.6.1.5.5.7.1.1) and the CDP extension (OID 2.5.29.31) off the wire, and both contained only ldap:/// URLs, with no http://. That is the install’s default state, exactly the one this section warns about.

The consequence is not theoretical. When I built the certificate’s chain on a machine that was not a domain member, the build failed: the client couldn’t reach the LDAP URL the certificate pointed at, so it couldn’t fetch the issuer certificate or the CRL. The Build result came back false. That is the “off-site laptop” case, live: a domain-member machine validates the same certificate without a hitch because it can read the directory, and a machine one step outside the domain can’t. The fix is not on the client; it’s to define a reachable http:// address in the Extensions tab before issuing the certificates those devices will use.

Verifying the Install: Is the CA Up, Did It Write to AD?

Installed does not mean working. You verify from both sides.

Server Side: Service and Console

Check the state of the CA service:

Get-Service CertSvc

Status   Name      DisplayName
------   ----      -----------
Running  CertSvc   Active Directory Certificate Services

Then open the Certification Authority console. There should be a green mark next to the CA name; a red stop mark means the service is stopped.

Directory Side: Did the CA Write Itself to AD?

This is the real verification, because it’s exactly where an Enterprise CA differs from a Standalone. The record that lets domain-member clients find the CA lives in Active Directory:

CN=Enrollment Services,CN=Public Key Services,CN=Services,
CN=Configuration,DC=ad,DC=sercebilisim,DC=com

Inside this container there should be an object representing your CA. If it’s empty, the CA was either installed as Standalone or configured with an account that has no rights to write to AD; in both cases autoenrollment won’t work.

Without opening a console, you can query the same container with PowerShell from a domain controller:

$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$config" `
  -Filter 'objectClass -eq "pKIEnrollmentService"' -Properties dNSHostName |
  Select-Object Name, dNSHostName

The returned row shows the CA’s name and the server it runs on. If no row comes back, the container is empty; even if the CA is up, domain members can’t find it.

Which Console Opens with Which Command?

There is more than one console on the certificate side, and opening the wrong one makes you think an existing certificate isn’t there.

End-to-End: Did a Client Actually Get a Certificate?

The CA being up doesn’t mean a certificate can be obtained from it. The fastest proof is the domain controller itself: if a suitable template is published, domain controllers request their certificates by autoenrollment on their own, and you have to do nothing for it.

On the domain controller, open certlm.msc and look at the Personal → Certificates branch.

Three columns are checked: Issued To should be the server’s FQDN, Issued By should show the name of the CA you just installed, and Certificate Template should say which template it came from. If all three are in place, the CA works end to end.

If the list is empty the CA isn’t broken; autoenrollment simply hasn’t been triggered yet. Rather than wait for Group Policy to refresh on its own, trigger it by hand on the server:

gpupdate /force
certutil -pulse

If one of the three verification steps fails, see the error list below.

Back Up the CA: Three Parts, Three Places

The CA is up and running. The next job is to protect it against loss, because losing this machine is not the loss of a single server: if the CA goes, so does the signing basis behind every certificate it issued. What you back up is not one file but three separate parts, and each lives somewhere different.

Certificate templates are not part of these three. They live not on the CA but in Active Directory’s Configuration partition, that is, in the domain controller’s system state backup. This is the most often missed piece: realising you backed up the CA but not the templates usually happens on restore day.

Key, Certificate and Database

All three are taken with one command, on the CA’s own console. The target folder must be empty; if it’s full the command refuses:

certutil -backup C:\ca-yedek

The folder name is the lab’s own (yedek is Turkish for backup); it’s left as captured so the command matches the output. The command asks for a password partway through: this is the password for the .p12 file that wraps the private key. In our lab install the output was:

Backed up keys and certificates for ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA to C:\ca-yedek\SerceBilisim-Lab-Root-CA.p12.
Full database backup for ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA.
Backing up Database files: 100%
Backing up Log files: 100%
Truncating Logs: 100%
Backed up database to C:\ca-yedek.
Database logs successfully truncated.
CertUtil: -backup command completed successfully.

The Truncating Logs line is normal: because -backup takes a full backup, it truncates the processed logs. The registry configuration is not part of this command; you take it separately:

reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\ca-yedek\ca-config.reg

This file carries the AIA and CDP addresses, the CRL publishing intervals and the validity settings; without them, after a restore the CA starts stamping the wrong addresses.

Two Different Rhythms

The CA’s two parts change at different speeds, and the backup schedule should follow that.

The private key never changes. It’s generated at install and stays the same until the CA is renewed. Back it up once, put it somewhere safe and offline, and don’t touch it again. Backing it up every night is pointless; what matters is where it’s kept.

The database changes with every certificate issued. This is the part that wants a regular backup, and it can be taken on its own, without exporting the private key again:

certutil -backupDB C:\ca-yedek-db

Once the key is safely put away, the right arrangement is to run -backupDB daily from a scheduled task.

Common Mistakes When Installing AD CS

The faults in this section share one trait: the symptom doesn’t point at the cause. None of them throws an error; an option is greyed out, a list looks empty, or everything looks like it’s working.

The Enterprise CA Option Is Greyed Out

Symptom: On the Setup Type screen only Standalone CA can be selected, Enterprise CA can’t be clicked. The wizard doesn’t say why.

Cause: The signed-in account is not a member of Enterprise Admins. Domain Admins isn’t enough here, because an Enterprise CA writes itself into the forest’s Configuration partition, which is forest-level, not domain-level.

Fix: Run the configuration with an account that’s a member of Enterprise Admins. This is a temporary right needed for the install; Enterprise Admins should not sit permanently on a day-to-day account.

But my real advice is to check this before you enter the wizard. I did that in my own install and I’m glad I did, because my day-to-day admin account was a member of Domain Admins only. It’s a right that looks sufficient at first glance and isn’t; the wizard won’t tell you, it just greys out the option. Known in advance, it’s a thirty-second account switch; unknown, it turns into cancelling the wizard, going back, and hunting for “what did I do wrong.”

The CA Is Installed but No Machine Gets a Certificate

Symptom: The CA console is green, the service is running, but the Issued Certificates folder stays empty and servers have no certificate.

Cause: Autoenrollment hasn’t been triggered yet. The CA existing and clients getting certificates from it are two different jobs; the bridge between them is a Group Policy refresh, and doing it on its own can take up to an hour and a half.

Fix: On the server in question, run gpupdate /force and then certutil -pulse to shorten the wait. If the certificate still doesn’t come, check the template permissions: the computer account or group may not have enrol rights on the template.

The Certificate Exists but Isn’t in the List

Symptom: You know the server got a certificate, but you see an empty list in the console.

Cause: Looking in the wrong store. Server and domain-controller certificates live in the computer store; certmgr.msc opens the signed-in user’s store.

Fix: Open certlm.msc and look at the Personal → Certificates branch.

Certificates Carry the Wrong Revocation-List Address

Symptom: Certificates look valid but validation hangs on some clients, especially those off-site.

Cause: The CDP address was fixed after the first certificates were issued. A change on the Extensions tab affects only new certificates.

Fix: Fix the address, then reissue the certificates that went out with the wrong one. That’s the only real fix for this fault; there’s no shortcut.

A Standalone CA Was Installed by Accident

Symptom: The CA works but there’s no trace of it on the Active Directory side: the template list is empty, autoenrollment never kicks in, clients can’t find the CA.

Cause: Standalone CA was selected on the Setup Type screen. A Standalone CA writes nothing to the directory.

Fix: This is not fixable with a setting. The CA is removed and reinstalled as Enterprise. The fastest way to check is the Enrollment Services query in the verification section: if the container is empty, the link to the directory was never made.

The Server Was Renamed After Install

Symptom: Certificates that worked a day earlier are invalid across the board.

Cause: Renaming the computer after AD CS is installed invalidates every certificate that CA issued.

Fix: The way back is expensive: remove the CA and return the machine to its old name, or reinstall the CA with the same keys and fix the registry by hand. This is why name and IP are fixed before install, and why the CA is not installed on machines whose name and role can change, particularly domain controllers.

Certificate Templates: Which Template, Which Permission

Before a certificate is issued from the CA, you decide which template it uses. The template determines how long the certificate lasts, what purpose it’s valid for, and who may request it. Templates are managed through the Certificate Templates Console (certtmpl.msc).

The built-in templates do the job but aren’t used directly. The reason is in the third item: who may request it. Most of the rejections you hit when trying to get a certificate come from here, and the error message won’t tell you so.

The Lesson from Our Lab: Who Is Requesting?

Issuing a certificate to our web server, I tried three approaches in turn and two were rejected. The order matters, because each rejection came for a different reason than the last.

First attempt, IIS’s own wizard. Create Domain Certificate issued the certificate without trouble. But the browser refused to open the site:

ERR_CERT_COMMON_NAME_INVALID

This is a name error, not a trust error. The internal CA was already trusted; the problem was that the certificate’s SAN (Subject Alternative Name) field was empty. Browsers stopped reading the name from the CN field years ago. With no SAN, the certificate is technically valid and practically unusable.

Second attempt, certlm.msc and Get-Certificate. I tried these tools for a request with a SAN, and both were rejected. The reason only became clear once I read the template’s permission list: these tools send the request with the machine account, and the template I was using granted Enroll only to admin groups. The machine account wasn’t on that list.

The real lesson: a template permission is not a list of users, it is the list of which identity may send the request. Changing the tool isn’t enough; you need to know who is sending the request.

Open Your Own Template by Copying

Don’t edit a built-in template directly, copy it; the built-in ones can change with updates.

1. In certtmpl.msc, right-click the template and choose Duplicate Template.
2. On the General tab, give it a distinctive name and a sensible validity period.
3. On the Security tab, grant Enroll to the identity that will request the certificate. If servers will request on their own behalf, that permission goes to a computer group, not an administrator.
4. On the Subject Name tab, tick Supply in the request; this is required if the request itself will carry the SAN.
5. Don’t forget to publish the template: in the CA console, Certificate Templates → New → Certificate Template to Issue. Skip this and the template exists but the CA doesn’t recognise it.

Autoenrollment Reaches Domain Members, Not Others

The template is ready. Next is how the certificate reaches the machines, and here the road splits in two.

On domain-member machines the job runs itself. Autoenrollment is turned on through Group Policy; when the machine logs on to the domain it applies to the CA with its own identity, and if the template grants Enroll and Autoenroll it gets the certificate and renews it itself before expiry. The administrator does nothing.

The only reason this chain works is this: the machine is already an object with an identity in the domain. The CA knows it, verifies it with Kerberos, looks for it on the permission list.

On a non-domain machine the first link of that chain doesn’t exist. If a Linux server, a web server in the DMZ, or a network device isn’t a domain member:

• Group Policy doesn’t reach it, so autoenrollment is never triggered.
• It has no machine account to identify itself to the CA.
• When the certificate expires, nobody renews it; the expiry arrives silently.

The result: on every non-domain machine the certificate is obtained by hand and renewed by hand. This is not a shortcoming, it’s the natural boundary of the architecture. But in infrastructures built without knowing it, it comes back two years later as services failing in the same week.

Certificates for Non-Domain Servers: Requesting with certreq

We’ll carry the certificate by hand to a machine autoenrollment doesn’t reach. The flow is three steps, and even though the machine is outside the domain, the CA is still your AD CS:

1. A key pair and a request file (CSR) bound to it are generated on the server.
2. The request is sent to the CA from a domain-member machine and signed.
3. The signed certificate and the root chain are carried back to the server and bound to the service.

The most critical part is the second step: the private key never leaves the server. What’s carried is only the request file and the signed certificate; neither is secret.

The INF File That Defines the Request

On the Windows side a text file defines the request. You have to write the SAN here, because the GUI wizard leaves it empty:

[NewRequest]
Subject = "CN=portal.ad.sercebilisim.com"
KeyLength = 2048
KeyAlgorithm = RSA
MachineKeySet = TRUE
Exportable = TRUE
RequestType = PKCS10

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=portal.ad.sercebilisim.com&"

Two lines carry the decision. MachineKeySet = TRUE writes the key to the machine store rather than the user store; IIS and similar services can only see the certificate there. 2.5.29.17 is the object identifier of the SAN extension, and without this block you’re back to the name error above.

Send the Request

certreq -new request.inf request.req
certreq -submit -attrib "CertificateTemplate:ServerCertificate" request.req certificate.cer
certreq -accept certificate.cer

In our install this was exactly the path that worked, and the importance of who sends the request showed up here: I ran the command not with the machine account but with an admin account that had Enroll permission on the template. The issued certificate was signed by the internal root CA, the SAN field was populated, and the browser opened the site without objection.

The Same Flow for Linux Servers

On Linux the only thing that changes is how the request is generated; the rest stays the same. I ran the steps below on an Ubuntu server that was not a domain member and had our internal CA sign the certificate.

The key and request are generated with openssl. You have to supply the SAN by hand here too:

openssl req -newkey rsa:2048 -nodes \
  -keyout sercesyslog.key -out sercesyslog.csr \
  -subj "/CN=sercesyslog.ad.sercebilisim.com" \
  -addext "subjectAltName=DNS:sercesyslog.ad.sercebilisim.com,DNS:sercesyslog,IP:192.168.1.46"

Before sending, verify the request actually carries what you want; noticing that the SAN didn’t make it in after the CA has already returned a certificate is expensive:

openssl req -in sercesyslog.csr -noout -verify
openssl req -in sercesyslog.csr -noout -text | grep -A1 "Subject Alternative Name"

Certificate request self-signature verify OK
            X509v3 Subject Alternative Name:
                DNS:sercesyslog.ad.sercebilisim.com, DNS:sercesyslog, IP Address:192.168.1.46

This is where most guides stop. The .csr you produced does nothing on its own, and because the Linux machine isn’t in the domain it can’t apply to the CA itself. You carry the file to a domain-member Windows machine and send the request from there. To send it to a remote CA you use the -config parameter:

certreq -submit -config "ca01.ad.sercebilisim.com\SerceBilisim-Lab-Root-CA" -attrib "CertificateTemplate:WebServer" sercesyslog.csr sercesyslog.cer

RequestId: 7
Certificate retrieved(Issued) Issued

The word Issued says the certificate was signed. If the template defines an approval requirement you’ll see Taken Under Submission instead; then the request waits in the queue and no certificate is produced until it’s approved from the CA console.

After carrying the returned file and the root certificate back to the Linux server, verify two things. First, that the certificate really belongs to your key; the public-key modulus of the two must match:

openssl x509 -in sercesyslog.cer -noout -modulus | openssl md5
openssl rsa  -in sercesyslog.key -noout -modulus | openssl md5

MD5(stdin)= 0a0f9ba7b77fef6f38f1db53fb8cecda
MD5(stdin)= 0a0f9ba7b77fef6f38f1db53fb8cecda

Second, that the chain closes, that is, that the certificate really was signed by that root:

openssl verify -CAfile root-ca.cer sercesyslog.cer

sercesyslog.cer: OK

Finally, look inside the certificate. You want three things: is the SAN preserved, is the issuer the right CA, and is the intended use server authentication?

subject=CN = sercesyslog.ad.sercebilisim.com
issuer=DC = com, DC = sercebilisim, DC = ad, CN = SerceBilisim-Lab-Root-CA
notBefore=Aug 19 02:23:23 2026 GMT
notAfter=Aug 18 02:23:23 2028 GMT
            X509v3 Subject Alternative Name:
                DNS:sercesyslog.ad.sercebilisim.com, DNS:sercesyslog, IP Address:192.168.1.46
            X509v3 Extended Key Usage:
                TLS Web Server Authentication

All three are in place. You can now bind the certificate to the service; on the Apache side three lines are enough:

SSLCertificateFile      /etc/ssl/certs/sercesyslog.cer
SSLCertificateKeyFile   /etc/ssl/private/sercesyslog.key
SSLCACertificateFile    /etc/ssl/certs/root-ca.cer

In a small environment you can also run your own authority on Linux instead of AD CS; we showed the shortest form of that with openssl, measured, in the TLS section of the syslog server guide. A Linux CA at enterprise scale, with its revocation list, subordinate CA and renewal arrangement, is a separate subject.

Conclusion: The Install Is Done, the Real Work Starts Now

Standing up AD CS is half a day. The decisions that outlast it are the four engraved at install, the AIA/CDP addresses set before the first certificate, and the template permission that decides who may request. Get those right and the CA disappears into the background, quietly signing; get one wrong and it comes back months later as a fault whose symptom never mentions certificates. The machine is up. What matters now is the discipline around it.