Checked against the current Windows build. Where an article names a menu, a button or a message, that is the wording in the application, not a paraphrase.
The list comes from your Windows personal store and nowhere else
Creasepoint reads the certificates in the personal store of the current Windows user and offers the ones it could sign with. When the panel says “No certificate with a private key in your Windows personal store”, that is a statement about Windows rather than about your token.
So check Windows first. Open Manage user certificates and look under Personal → Certificates with the token connected. From a command line, creasepoint certs prints the same list with each certificate’s thumbprint, common name, issuer, expiry date and whether it is currently valid. If both of those are empty, nothing inside this application will change the answer, and the fix is on the Windows side of the boundary.
The middleware is what puts a certificate there
A DSC token does not become a certificate by being plugged in. Its middleware — the vendor’s driver package, whether that is eMudhra, Watchdata, ePass, ProxKey or another — registers a cryptographic provider with Windows, and the certificate then appears in the personal store for as long as the token is connected. Without that package, Windows sees a USB device and nothing more. Those names are examples of what people in India actually have in a drawer, not a tested compatibility list — Creasepoint asks Windows for any certificate in your personal store that can sign, and does not know which vendor put it there.
Two habits of these packages are worth knowing. A new token sometimes needs its vendor utility run once before Windows lists anything at all. And listing certificates here never opens a private key, deliberately, because some providers prompt for the card the moment a key handle is opened; the PIN dialog you meet at signing time belongs to the token’s own driver, not to Creasepoint, and the private key never leaves the token.
Three reasons a certificate that is installed is filtered out
The list is not everything in the store. Three things remove a certificate before you ever see it.
- No private key on this machine. A
.cerfile holds the public half. It identifies you to other people and cannot sign anything. - A key type that cannot sign. RSA and ECDSA both work here, though for an Indian filing you want RSA — the signature profile India’s rules point at names RSA and no alternative. A certificate whose key is neither is left out of the list rather than offered and failed later, and no setting changes that.
- Key usage that excludes signing. A certificate whose key usage extension names encryption, and neither digital signature nor non-repudiation, is not offered, because a signature made with it sits outside what its issuer authorised.
An encryption-only certificate is rare on a DSC token. The other two are not. If creasepoint certs shows nothing while Windows shows a certificate under Personal, one of these three is why.
Listed, and still refused
An expired certificate is shown rather than hidden, with a caveat under its name giving the date, and sorted below the valid ones. Choose it and press Sign and the operation is refused: it expired on that date, and a signature made with it would be rejected by anyone who checked. A certificate that is not yet valid is treated the same way, with its start date.
A website certificate is shown too, labelled as one, and pushed down the list. It can sign a PDF perfectly well and is never what a person signing a document meant to pick — a machine that has collected server certificates over the years is how somebody signs a filing under the wrong identity. Read the common name and the issuer beneath it before you sign, rather than accepting whatever sits at the top.
If Windows still does not show it
A few things account for most of what is left. The store is per-user, so a certificate imported while signed in as somebody else is not yours to see. An import into the Local Machine store rather than Current User has the same effect. A token behind a hub or a docking station sometimes enumerates differently from one in the machine’s own port. And a middleware upgrade that went badly is usually cured by removing and reinstalling the vendor package rather than by anything subtler.
After any of those, choose Sign again — the list is read each time the tool is selected rather than once at startup, so there is no need to restart the application. If the certificate appears and signing then fails at the PIN stage, that exchange is between Windows and the token; the DSC signing guide covers what happens on our side of it.
The two places worth looking next.
Read the matching guide if you want the reasoning rather than the fix, and check limitations before spending any longer on it — some of what people look for here is absent on purpose.