Your phone as a smart card: PKI cards and the Windows CA.

A CodeB PKI card turns an Android phone with CodeB Wallet into a contactless smart card for a Windows PC with an NFC reader: the read/write card carries a certificate from your own CA whose private key is made in the phone’s secure hardware and never leaves it, the read-only card carries the member’s signing certificate from the server, and every use needs the card PIN. This guide explains how it works, how an administrator issues the cards, and how to set up the Windows certificate authority (AD CS) so certificates reach the phone.

How it works

1. The administrator issues a PKI card to a member on phone.codeb.io (admin page “PKI cards on phones”). The member gets an invitation link or QR code.
2. The member adds the card to CodeB Wallet. The phone proves that its key sits in secure hardware (key attestation); the card’s secrets reach only that phone, once, encrypted.
3. The member chooses a card PIN on the phone. The read-only card also shows its unblock code (PUK) once.
4. The certificate goes onto the phone from your own Windows CA: on the read/write card Windows creates the key and writes the certificate itself; the read-only card gets the member’s signing certificate from the server right after it is collected.
5. Use at the PC: the member opens the card in CodeB Wallet, taps “Use at PC”, holds the unlocked phone to the NFC reader, and Windows shows a smart card. The card PIN unlocks the key.

On the read/write card the certificate comes from your PKI: phone.codeb.io issues the card and its management keys, never sees that card’s private key and never issues the sign-in certificate. The read-only card is never empty: it carries the member’s signing certificate from phone.codeb.io, the same key that signs remotely for this member, so that key also exists on the server.

The two PKI cards

What you need

• phone.codeb.io tenant with an administrator account; PKI cards switched on for the site (admin page “PKI cards on phones”).
• Windows PKI: an Active Directory Certificate Services (AD CS) enterprise CA in the domain, as for plastic smart cards. Domain controllers need a certificate for Kerberos authentication.
• PCs: Windows 10 or 11 with a PC/SC (CCID) contactless NFC reader.
• Phones: Android 10 or newer with NFC card emulation (almost all Android phones with NFC) and CodeB Wallet (closed test phase). The phone must be unlocked while it is used as a card. The read-only card also needs an NFC chip that can route by application ID; the app checks this and tells the member if the phone cannot.
• Read-only card only: the signing certificate comes from the server with no set-up on your side; a Windows sign-in certificate on this card needs your organisation’s CodeB software, which comes later; ask CodeB.

Issue a PKI card (phone.codeb.io)

1. Sign in as administrator and open Admin → PKI cards on phones.
2. Switch PKI cards on for this site. While they are off, no card can be issued and the PC software cannot fetch card keys; cards already on phones keep working until they end or are revoked.
3. Under Issue a PKI card choose the member, the card (Read/write PKI card or Read-only PKI card), how many days it is valid (up to 1096, default 365) and how long the invitation stays open. Tick “E-mail the invitation to the member” to send it.
4. The member opens the link on the phone (or scans the QR code) and adds the card to CodeB Wallet. A card can be collected once, only with a key in secure hardware.
5. The list shows the state of each card: invitation open, active, ended or not collected, revoked. When the phone reports it, the Certificate column shows the serial number and issuer of the certificate on the card.

Everything on this page is also available as a JSON API for your own tools (see openapi.json, tag pki-cards).

Set up the Windows CA (AD CS)

The phone behaves like a smart card to Windows, so the CA set-up is the one you would use for plastic smart cards. Do it once per domain. The names below are those of the English Windows consoles.

1. Check the domain controllersEach domain controller needs a certificate for Kerberos authentication (template Kerberos Authentication or Domain Controller Authentication, usually autoenrolled). An enterprise CA is added to the NTAuth store automatically. Only if your issuing CA is not an AD CS enterprise CA, publish it with certutil -dspublish -f ca.cer NTAuthCA.
2. Duplicate the Smartcard Logon templateOpen certtmpl.msc, right-click Smartcard Logon and choose Duplicate Template. Give it a clear name, for example “CodeB Phone PKI Card”.
3. Compatibility tabCertification Authority: Windows Server 2016. Certificate recipient: Windows 10 / Windows Server 2016. This unlocks the Cryptography settings below.
4. General tab: validitySet the validity period no longer than the PKI card’s validity in the admin panel, so the certificate does not outlive the card.
5. Cryptography tab: key on the phoneProvider category: Key Storage Provider. Algorithm: RSA, minimum key size 2048. Choose “Requests must use one of the following providers” and select only Microsoft Smart Card Key Storage Provider. This makes Windows create the key on the card (the phone), not on the PC.
6. Request Handling tab: no exportLeave “Allow private key to be exported” off. The key is created in the phone’s secure hardware and cannot be exported anyway.
7. Subject Name tab: strong mapping“Build from this Active Directory information”, with the User principal name (UPN) in the alternate subject name. Do not choose “Supply in the request”. Domain controllers require a strong certificate mapping (Microsoft KB5014754): an up-to-date enterprise CA adds the account’s SID to certificates built from Active Directory automatically. Keep the CA and the domain controllers on current updates; otherwise add an explicit mapping (altSecurityIdentities).
8. Extensions tab: application policiesApplication policies must contain Smart Card Logon and Client Authentication (they are in the Smartcard Logon template already).
9. Security tab: who may enrolGive the users (or a group such as “Phone PKI card users”) Read and Enroll. Do not grant Autoenroll (see the Group Policy notes).
10. Issue the templateOpen certsrv.msc, right-click Certificate Templates → New → Certificate Template to Issue, and select the new template.
11. Revocation dataDomain controllers check the user’s certificate and the PCs check the domain controller’s certificate, so both must reach the CA’s CRL (or OCSP); smart card logon fails when it cannot be fetched. CRLs are cached until they expire, so use short CRL and delta CRL periods.

Put a certificate on the phone

Read/write PKI card: Windows enrols the certificate onto the phone

1. On the PC, sign in as the member (the certificate is requested for the signed-in user).
2. In CodeB Wallet open the read/write PKI card, tap Use at PC and hold the unlocked phone to the NFC reader. Keep it there during the next steps.
3. Open certmgr.msc → Personal → All Tasks → Request New Certificate, choose Active Directory Enrollment Policy, tick the “CodeB Phone PKI Card” template and click Enroll.
4. Windows asks for the card PIN, creates the key on the phone and writes the certificate onto it.
5. Check the result with certutil -scinfo -silent while the card is active. The admin panel shows the certificate’s serial number and issuer once the phone reports them.

The same from the command line (the template defines key and provider):

Use the template name (by default the display name without spaces, shown on the General tab). Do not add -q: Windows must be able to ask for the card PIN.

Read-only PKI card: the member’s signing certificate from the server

1. Issue the read-only card as above. When the member collects it, CodeB Wallet fetches the member’s signing certificate and key from the server (created if the member has none yet) and puts them in the card’s signature slot; then the member chooses the card PIN.
2. At the PC, Windows reads the card with its built-in driver and offers the certificate for signing, for example in Office or a PDF reader. Every signature needs the card PIN.

Being tested: CodeB Wallet fetches the signing certificate right after the card is collected; this is being tested in closed groups. The key is delivered once per card, encrypted to a key in the phone’s secure hardware that the phone proves with key attestation; it also stays on the server because the same key signs remotely for this member. Today the certificate is self-signed per member, so relying parties show an unknown signer unless they trust it; it is not a qualified or advanced electronic signature. The card’s sign-in slot stays free for a Windows sign-in certificate from your CA, set up by your organisation’s CodeB software, which comes later; ask CodeB.

Already have a certificate in the CodeB Key Storage Provider on the PC? The admin page “Copy a Windows certificate to a phone” describes how an existing certificate can be handed over to the phone instead (tested in closed groups).

Sign in with the phone

1. On the Windows sign-in screen choose Sign-in options → smart card (or press Ctrl+Alt+Del when the card is detected).
2. In CodeB Wallet open the PKI card and tap Use at PC; hold the unlocked phone to the reader.
3. Windows shows the smart card with the member’s certificate. Enter the card PIN.
4. The same works for other certificate uses on the PC (for example signing or a web sign-in with a client certificate) while the card is active. For those, the Windows Certificate Propagation service must be running, so the card’s certificate appears in the user’s store.

Confirmed in a closed-group test: Windows sign-in to a domain account (Kerberos smart card logon) with a read/write PKI card and its card PIN. Cached sign-in and further set-ups are being tested. The read-only PKI card has no sign-in certificate. Only the chosen card answers, only while its card screen is open and the phone is unlocked. Door access, payment apps and other cards on the phone are not affected.

Group Policy notes

• Smart card removal behaviour (Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Interactive logon: Smart card removal behavior): Windows sees a card removal when the phone is taken off the reader or the card screen is closed. With “Lock Workstation” the PC would lock every time the phone is taken away. Recommended: “No Action” on PCs where phones are used as PKI cards. (The policy only applies while the Smart Card Removal Policy service runs.)
• Require smart card (Interactive logon: Require Windows Hello for Business or smart card): switch it on only after the phone cards work for all affected users, and keep a recovery path.
• Autoenrolment (User Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment): the phone is a card only while “Use at PC” is active, so a manual request (above) is the reliable way to enrol it.

Lost phone and revocation

1. In the admin panel, revoke the PKI card. The card stops answering once the phone receives the revocation (through the status list).
2. Revoke the certificate at your CA (certsrv.msc → Issued Certificates → Revoke Certificate) and publish a new CRL. Until the cached CRLs on the domain controllers expire, the certificate can still sign in, so keep CRL periods short. The admin panel shows the serial number to look for when the phone reported it.
3. Read-only card: revoking it stops the card only. The member’s remote-signing key and certificate stay until they are revoked separately.
4. Issue a new PKI card to the member’s new phone and enrol a new certificate.

Security

• The private key is created and kept in the phone’s secure hardware (StrongBox, otherwise the TEE). It cannot be exported, and every use needs the card PIN.
• A card is collected once, only by a phone whose key attestation is valid. Its management key (and the read-only card’s PUK) are made by the server and delivered once, encrypted, to the key that collected the card; the app never shows them.
• The server never sees the card’s private key or the card PIN. It stores only what the administrator needs: the card, its state and, if reported, the certificate’s serial number and issuer.
• Wrong PINs block the card (read/write card after 5, read-only card after 3). Only the chosen card answers, while its card screen is open and the phone is unlocked; a locked phone refuses. It stops when the phone is taken off the reader or the card screen is closed.
• No database: every record is a file on your own server, encrypted where it holds a secret.

Troubleshooting

• Windows says the card needs a driver, or nothing reaches the phone: some Android phones have an NFC setting that sends card commands to a built-in secure element instead of to apps. Open Settings → Connection & sharing → NFC and set Secure element position to HCE Wallet (the names differ by phone). Then hold the phone to the reader again with the card screen open.
• Enrolment fails with CERTSRV_E_SUBJECT_EMAIL_REQUIRED: the template puts the e-mail address into the certificate, but the user’s Active Directory account has none. Give the user an e-mail address in Active Directory, or untick the e-mail options on the template’s Subject Name tab.
• The certificate request is signed with SHA-1: templates in the legacy CSP provider category default to SHA-1. Use provider category Key Storage Provider on the Cryptography tab with request hash SHA256.
• The card stops in the middle of enrolment: creating the key can take several seconds. Keep the phone at the reader with the card screen open until Windows reports the result.

Questions

Last updated: 2026-10-19

Related