Certificates from the corporate PKI (Microsoft AD CS)

Applies to: SimpleTwo 0.9.361 · Checked: 19.10.2026

If the company's devices and computers already trust the root of a corporate certification authority (CA) on Microsoft AD CS, a certificate for SimpleTwo is easier to issue there than at Let's Encrypt. This is above all for meeting-room hardware (Poly, Cisco): it usually has the corporate root installed already, and Let's Encrypt cannot issue the MCU site names (*.ru.mcu.example.com) over HTTP-01 — they point at several nodes at once.

The console does it without anyone handling keys:

The coordinator writes the request (CSR) and keeps its private key. The key is never shown and cannot be downloaded; with encryption at rest on it is sealed under the master key, like the other keys the coordinator keeps for others.
You have the request signed by the corporate CA — with Send to certsrv straight from your browser (recommended: the coordinator does not need to reach the CA) or with certreq.
You bring back the issued certificate (.cer or .p7b); the coordinator finds the request by its key, completes and checks the chain, shows what the certificate will cover, and installs it.

All of it is in Settings → Certificate from the corporate PKI (Microsoft AD CS). The Telephony → SIP SRV records → Certificate for the MCU sites card links there with Request from the corporate PKI….

1. What a certificate can be requested for

Purpose	Default names	Where the certificate goes
MCU sites	the MCU domain, `.<MCU domain>`, `.<site>.<MCU domain>` for each site, each node's name `<node>.<site>.<MCU domain>`	the MCU sites certificate — every MCU node gets it (Meeting rooms, section 5)
A role's host — TURN, SFU, an MCU node by its public name, the PSTN gateway, MX, monitoring	the host's public name	that host's certificate; Let's Encrypt is no longer ordered for it
Coordinator (console and apps)	the domain from Settings → TLS and the tenant domains	the console's own certificate — like a manual import in Settings → TLS

The names can be edited: added, removed, replaced. A wildcard is allowed in the first label only (*.ru.mcu.example.com).

Who must trust the root

A certificate from the corporate CA is accepted only by devices that have the corporate root. For the MCU sites and internal hosts that is fine. The coordinator is also opened from employees' personal phones — with a corporate certificate the apps on them will not connect unless the root is installed there.

Roles that obtain their certificate themselves (chats, directory, mail, drive, ID) are not offered: they have no way to import a certificate.

2. Settings (once)

At the bottom of the card, Settings:

Certificate template — the template's name, not its display name. For the stock "Web Server" template it is WebServer (the default). If the company has its own server template, enter its name.
CA for certreq (-config) — <CA host>\<CA name>, e.g. ca01.corp.local\Corp Issuing CA. Optional: without it certreq asks for the CA in a picker.
Web enrollment address — https://<CA host>/certsrv, e.g. https://ca01.corp.local/certsrv. Send to certsrv posts the request there from your browser. The page address from the browser (…/certsrv/certrqxt.asp) or a bare host name also works — the console turns it into https://<host>/certsrv. An http:// address is accepted with a warning: over it your Windows credentials and the request cross the network unprotected.
Remind days before expiry — 30 by default.
Corporate CA certificates — the issuing CA and the root. No need to fill them in by hand: they are remembered from the first .p7b that carries the chain.

Organization, department, country, city and region (O, OU, C, L, ST) are remembered from the last request.

What the template must be

a "Web Server" type: Extended Key Usage includes Server Authentication;
Subject Name: Supply in the request — otherwise the CA builds the name from AD and drops the request's names (SAN), and the certificate will not do. The stock "Web Server" template has it;
your account (or group) has Enroll on the template's Security tab;
the template is published on the issuing CA (Certificate Templates → New → Certificate Template to Issue).

A stand-alone (not AD-integrated) CA has no templates; to make it take SANs from the request the CA administrator runs certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2.

3. The request

Purpose — e.g. "MCU sites". The names and the common name (CN) are filled in.
Key — RSA 2048 (the default: every meeting-room device understands it), RSA 3072 or ECDSA P-256.
Check the names and subject fields, press Generate request.

The console shows the request (CSR) — copy it or download it as a .req file — and ready-made instructions with your template and file name.

Send to certsrv from the browser (recommended)

The coordinator usually cannot see the corporate CA — your browser can, and it signs in to Web Enrollment (certsrv) with your Windows account. So the browser submits the request, not the coordinator:

Press Send to certsrv under the request (or in a pending request's row of 3. Certificates and requests). A new tab opens and submits the request to <web enrollment address>/certfnsh.asp with the template from the settings — just as certsrv's "advanced certificate request" does. If the browser asks for a user name and password, it is the CA asking, not the coordinator.
Certificate Issued: choose Base 64 encoded and press Download certificate chain. Drop the downloaded .p7b onto the card — the console checks it at once (§4). One file is enough: the chain carries the certificate.
Certificate Pending: the CA waits for a certificate manager's approval. Note the Request Id certsrv shows. Once approved, come back in the same browser to <address>/certsrv → View the status of a pending certificate request (certsrv remembers requests in a browser cookie) — or type the Request Id into the field under the request in the console: it gives a direct link <address>/certnew.p7b?ReqID=<n>&Enc=b64 to the chain.
Denied, or an error about the template — check the template's name, "Subject Name: Supply in the request" and your Enroll permission (§2).

The private key goes nowhere: only the CSR is sent to the CA, and it is not secret. The request and the template reach the new tab in the address's fragment (#…), which the browser never sends anywhere — not to the coordinator, not in a Referer.

Why the file has to be dropped by hand

The console cannot pick the certificate up by itself: certsrv sends no CORS headers, so only the tab that asked can read the CA's answer, and the console (another address) may not. The coordinator usually cannot reach the CA at all. So the last step is one file dropped onto the card.

Or with certreq

On a domain computer that can reach the CA:

certreq -submit -attrib "CertificateTemplate:WebServer" mcu-sites-1a2b3c.req mcu-sites-1a2b3c.cer

Naming the CA (when it is set in the settings, the console fills it in):

certreq -submit -config "ca01.corp.local\Corp Issuing CA" -attrib "CertificateTemplate:WebServer" mcu-sites-1a2b3c.req mcu-sites-1a2b3c.cer

If the CA holds the request for a certificate manager's approval, certreq prints a RequestId. Once approved:

certreq -retrieve -config "ca01.corp.local\Corp Issuing CA" 1234 mcu-sites-1a2b3c.cer

Do not run certreq -accept: the request's key is not on that computer, it is in the coordinator.

Or by hand in certsrv

When the button cannot be used (for example, no web enrollment address is set):

Open https://<CA>/certsrv → Request a certificate → advanced certificate request.
Paste the whole request text (from -----BEGIN CERTIFICATE REQUEST----- to -----END…).
Certificate Template — "Web Server" (or yours). Press Submit.
Choose Base 64 encoded and Download certificate chain — a .p7b with the issuing CA and the root. Download certificate (.cer) also works once the CA certificates are in the settings.

4. Installing the issued certificate

In 2. Install the issued certificate:

Request — "Any pending request" is fine: the certificate finds its request by its key.
Drop the file from certsrv onto the card (into the "Drop the file from certsrv here" box) — it is checked at once — or choose the file (.cer, .crt, .pem, .p7b), or paste the certificate as text (base64 or PEM).
If the file has no chain and the CA certificates are not saved yet, open CA certificates, when the file does not carry them and paste the issuing CA and the root (on a domain computer: certutil -ca.cert issuing.cer; the root from "Trusted Root Certification Authorities").
Press Check. The console shows who issued it, the validity, the chain, every requested name (✓ or ✗), and for the MCU sites — per node what will cover each of its names.
With no errors — Install. The hosts pick it up on their next poll, within about a minute.

What is checked, and why a certificate may be refused:

Message	What to do
the chain cannot be built up to a root	add the issuing CA and the root, or upload the `.p7b` instead of the `.cer`
the certificate does not name … / no alternative names at all	the template does not take names from the request — "Subject Name: Supply in the request" (§2)
not for server authentication	issue it from a "Web Server" type template
neither Digital Signature nor Key Encipherment	the same: the template is not for a TLS server
not issued for this request's key	it belongs to another request (or is an old one); pick the right request or file

The CA certificates of the chain are remembered: the next certificate can be brought as a bare .cer.

5. Expiry and renewal

The 3. Certificates and requests table shows the purpose, names, state, issuer and the expiry date.

N days before expiry (the setting, 30 by default) the console's main page shows a warning, after expiry an error. Only a certificate still in use is reminded about: if another one was imported over it, the row reads "installed, no longer served".
Renew writes a new request with the same names and a new key. Sign it the same way; the current certificate serves until the new one is installed, and then the old one reads "replaced by a newer one".
Cancel on a pending request deletes its key: a certificate issued for it can no longer be installed.

The console does not revoke anything in AD CS — the CA administrator does.

6. Example: the MCU sites certificate for s2, and the Poly devices

The s2 installation: MCU domain mcu.s2.itglobal.com, one site ru with nodes mcu1 and mcu2.

1. The request. Purpose MCU sites. The console fills in:

mcu.s2.itglobal.com
*.mcu.s2.itglobal.com
*.ru.mcu.s2.itglobal.com
mcu1.ru.mcu.s2.itglobal.com
mcu2.ru.mcu.s2.itglobal.com

mcu.s2.itglobal.com — the global SRV domain (for a device with no site);
*.mcu.s2.itglobal.com — covers the site domain ru.mcu.s2.itglobal.com (and future sites);
*.ru.mcu.s2.itglobal.com and the node names — the SRV targets; the node names are listed explicitly because not every device matches a wildcard against an SRV target.

CN mcu.s2.itglobal.com, key RSA 2048, template WebServer (or the company's server template). Generate request.

2. Signing. Send to certsrv → in the new tab, Certificate Issued → Base 64 encoded → Download certificate chain → drop certnew.p7b onto the card.

Or Download .req and, on a domain computer:

certreq -submit -config "<CA host>\<CA name>" -attrib "CertificateTemplate:WebServer" mcu-sites-xxxxxx.req mcu-sites-xxxxxx.cer

or certsrv → advanced request → "Web Server" → Base 64 → Download certificate chain.

3. Installing. A dropped file is checked at once (or choose the file and press Check): all five names ✓; for mcu1 and mcu2 the names ru.mcu.s2.itglobal.com, mcu.s2.itglobal.com and mcuN.ru.mcu.s2.itglobal.com read "this certificate". Install. A minute later the SIP SRV records card shows the site domain of both nodes covered by "MCU certificate".

The nodes' public names (mcu1.s2.itglobal.com, mcu2.s2.itglobal.com) are not in this certificate and keep being served with the node's Let's Encrypt certificate: a node picks the certificate by the name the device asked for.

4. The Poly devices. The line is set up as in Meeting rooms, section 9:

Parameter	Value
`reg.1.server.1.address`	`ru.mcu.s2.itglobal.com`
`reg.1.server.1.port`	`0` — find the nodes by SRV
`reg.1.server.1.transport`	`TLS`

The corporate root is usually on the devices already (the provisioning server hands it out). If not, load it into the device: web interface → Settings → Network → TLS → Certificates (or the device.sec.TLS.customCaCert1 parameter with the root's PEM text) and select it in the TLS profile SIP uses. Do not turn off certificate name checking on the device: it is what the certificate was issued for.

Check: the device registers over TLS, the MCU log on the node shows no handshake errors, and a call into a meeting works through either node.

1. What a certificate can be requested for​

2. Settings (once)​

What the template must be​

3. The request​

Send to certsrv from the browser (recommended)​

Or with certreq​

Or by hand in certsrv​

4. Installing the issued certificate​

5. Expiry and renewal​

6. Example: the MCU sites certificate for s2, and the Poly devices​