ACTALIS (ACe 2025) Italian CNS card not working

[matteobin]

Describe the bug

I can't use my new ACTALIS (ACe 2025) Italian CNS card with Mozilla Firefox to authenticate to government sites.

I would be happy to sponsor some work on this issue.
Do OpenSC developers accept donations?

By the way, I've even started a thread on opensc-devel mailing list, since I do prefer mailling lists to web interfaces.
https://sourceforge.net/p/opensc/mailman/opensc-devel/thread/20260815060545.matteobin.GA2904%40mail.tiepi.it/#msg59373942
So I'll write this issue updates on the mailing list as well.

Steps to reproduce

Some basic tests using pkcs11-tool:

$ pkcs11-tool -l -t

Using slot 0 with a present token (0x0)
Logging in to "MATTEO BINI".
Please enter User PIN:
error: PKCS11 function C_Login failed: rv = CKR_USER_PIN_NOT_INITIALIZED (0x102)
Aborting.

I got the card ATR using opensc-tool:

$ opensc-tool -a

Using reader with a card: bit4id miniLector-EVO 00 00
3b:ff:18:00:ff:81:31:fe:4d:00:6b:04:04:b8:5b:01:f1:01:43:4e:53:10:31:80:9d

The driver opensc uses with the card:

$ OPENSC_DEBUG=9 opensc-tool -n 2>&1 | grep -i itacns

P:31955; T:0x140552569972800 17:05:31.924 [opensc-tool] card.c:337:sc_connect_card: trying driver 'itacns'
P:31955; T:0x140552569972800 17:05:31.926 [opensc-tool] card-itacns.c:144:itacns_init: called

Expected behavior

My previous card used to work, then it expired and I got the new ACTALIS (ACe 2025) model.
https://sistemats1.sanita.finanze.it/portale/elenco-driver-cittadini-modalita-accesso

Actual behavior

I can't login to government sites with Mozilla Firefox and no certificate gets shown in the Security tab of the browser settings window.

OpenSC version

commit a6f4fdc

Operating system

Devuan GNU/Linux 5.0 (Daedalus)

Smart card model or security token

ACTALIS (ACe 2025) Italian CNS

Application used with smart card

Mozilla Firefox

Logs and debug output

Checklist

• I am using a supported OpenSC version
• I have searched existing issues to avoid duplicates

[ale-rinaldi]

I looked into this a bit. The reason itacns recognizes the card (you get the holder name) but C_Login then fails with CKR_USER_PIN_NOT_INITIALIZED and no certificate shows up is that itacns builds the PIN object together with a key/cert pair: if it doesn't find a certificate, it never creates a PIN either, so the token ends up with a slot but no usable objects.

On these newer ACTALIS (ACe 2025) cards the CNS certificate and PIN don't sit at the classic MF-relative path (3F00/1100/1101) that itacns probes. itacns can still read the personal-data file (that's where the name comes from), but the CNS objects live behind a dedicated card application, so it finds nothing and bails out — exactly your symptom.

Before writing a patch it'd help to confirm where the certificate actually lives on your card. Could you run this (no rebuild needed — all in one invocation so it stays in the same card session) and paste the output?

opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A \
             -s 00:A4:01:0C:02:DA:01 \
             -s 00:A4:02:0C:02:C0:01 \
             -s 00:B0:00:00:00

The first line selects the CNS application these cards use; the next two step into the DF/EF where the certificate is expected, and the last reads it. The status words at each step (and whether the read returns a 30 82 … DER blob) will tell us the exact location. If the second or third SELECT returns 6A 82, try DA:11 instead of DA:01 on the second line — there seem to be two slots.

With that confirmed I can put together a small itacns change and a branch you can build and test.

[matteobin]

Thank you Alessandro for the quick reply! Here's the output you asked: $ opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A \ -s 00:A4:01:0C:02:DA:01 \ -s 00:A4:02:0C:02:C0:01 \ -s 00:B0:00:00:00 Using reader with a card: bit4id miniLector-EVO 00 00 Sending: 00 A4 04 00 0C A0 00 00 05 30 00 0B 10 40 01 02 1A Received (SW1=0x6C, SW2=0x00) Sending: 00 A4 01 0C 02 DA 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 A4 02 0C 02 C0 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 B0 00 00 00 Received (SW1=0x69, SW2=0x86)

[ale-rinaldi]

Thanks, that's already helpful. My fault on the first line: that SELECT needs a length byte — the 6C 00 is the card asking us to re-send with an Le — so the application wasn't actually selected and the two following SELECTs ran against the wrong context (hence the 6A 82 / 69 86).

Could you retry with 00 appended to the first line?

opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \
             -s 00:A4:01:0C:02:DA:01 \
             -s 00:A4:02:0C:02:C0:01 \
             -s 00:B0:00:00:00

If the first line now returns 90 00 (or 61 xx), we're inside the CNS application and the DF/EF selects should reach the certificate — the final read would then start with 30 82 … (a DER blob). If DA 01 still gives 6A 82, try DA 11 on the second line.

If it still won't come out that way, the most reliable way to pin the exact path is to capture the APDUs the working official software exchanges with the card: on Linux pcsc-spy (from the pcsc-tools package) does exactly that — start it, then read or list the certificate with the vendor software, and paste the trace here. Happy to walk through it.

[matteobin]

I think we are making progress! $ opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \ -s 00:A4:01:0C:02:DA:01 \ -s 00:A4:02:0C:02:C0:01 \ -s 00:B0:00:00:00 Using reader with a card: bit4id miniLector-EVO 00 00 Sending: 00 A4 04 00 0C A0 00 00 05 30 00 0B 10 40 01 02 1A 00 Received (SW1=0x90, SW2=0x00): [RAW BYTES REDACTED, BECAUSE I'M NOT SURE IF THIS IS SENSIBLE DATA] [THEY DON'T LOOK ENOUGH TO ME TO BE THE CERTIFICATE BYTES THOUGH] Sending: 00 A4 01 0C 02 DA 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 A4 02 0C 02 C0 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 B0 00 00 00 Received (SW1=0x69, SW2=0x86)

[ale-rinaldi]

Good — the 90 00 on the first line means we're now correctly inside the CNS application, so that part is solved.

The 6A 82 on DA 01 just means this card lays its files out under that application differently from the older ones I was matching against. Rather than keep guessing file IDs blind (slow and tedious for you), it's much faster to look at what the working software actually does.

Two options, whichever is easier for you:

1. The response you redacted after the successful 90 00 select is just the application's File Control Information — file IDs, sizes, access rules; there's no personal data in it — so it's safe to paste. It sometimes lists the EFs directly, which may be all we need.

2. The definitive way: capture the APDUs the official software exchanges with the card. pcsc-lite ships pcsc-spy for this — it logs every command/response at the PC/SC layer. Roughly: run pcsc-spy in one terminal, then in another read or list the certificate with the vendor tool (or in Firefox via their PKCS#11 module), and paste the log here. I can help get pcsc-spy set up on Devuan if it's not straightforward.

Either one will show the exact path to the certificate, and from there the itacns change is simple.

[matteobin]

The first option is very easy for me because I haven't even installed the "official" software. ``` $ opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \ -s 00:A4:01:0C:02:DA:01 \ -s 00:A4:02:0C:02:C0:01 \ -s 00:B0:00:00:00 Using reader with a card: bit4id miniLector-EVO 00 00 Sending: 00 A4 04 00 0C A0 00 00 05 30 00 0B 10 40 01 02 1A 00 Received (SW1=0x90, SW2=0x00): 6F 46 81 02 70 2C 82 03 38 00 00 84 0C A0 00 00 oF..p,..8....... 05 30 00 0B 10 40 01 02 1A 83 02 3F 00 85 01 01 .***@***.***?.... 86 09 FF FF FF FF FF FF FF FF FF 8A 01 05 CB 18 ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF ........ Sending: 00 A4 01 0C 02 DA 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 A4 02 0C 02 C0 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 B0 00 00 00 Received (SW1=0x69, SW2=0x86) ``` To me the official software is the free software one. ;-} Anyway if the previous output isn't enough, in the next days I will install the official software and spy its inner working with pcsc-spy. Thank you for the help so far, you've been extremely kind.

[ale-rinaldi]

Ha, fair point on "official" software 😄 — and that FCI was useful. The tag 83 02 3F 00 says the application's own file ID is 3F 00: inside the application the card behaves as if it had its own master file. itacns probes the classic CNS certificate path 1100/1101 from the real MF and doesn't find it on your card (only the personal-data 1102 is there) — but the certificate almost certainly lives at that same 1100/1101 inside this application.

So one more probe — select the application, then walk to 1100/1101 inside it:

opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \
             -s 00:A4:01:0C:02:11:00 \
             -s 00:A4:02:0C:02:11:01 \
             -s 00:B0:00:00:00

If the final read starts with 30 82 …, that's the certificate.

If 11 00 returns 6A 82, the card is likely using a PKCS#15 layout under the app instead — in that case this second one-liner reads its EF.DIR, which points to everything:

opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \
             -s 00:A4:02:0C:02:2F:00 \
             -s 00:B0:00:00:00

One of these should reveal where the cert lives, and then the itacns change is straightforward. (pcsc-spy stays the sure fallback, but let's see if we can avoid the proprietary detour.)

[matteobin]

Maybe we will need the proprietary software after all: it seems to me that both of the following outputs don't contain the certificate. ``` $ opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \ -s 00:A4:01:0C:02:11:00 \ -s 00:A4:02:0C:02:11:01 \ -s 00:B0:00:00:00 Using reader with a card: bit4id miniLector-EVO 00 00 Sending: 00 A4 04 00 0C A0 00 00 05 30 00 0B 10 40 01 02 1A 00 Received (SW1=0x90, SW2=0x00): 6F 46 81 02 70 2C 82 03 38 00 00 84 0C A0 00 00 oF..p,..8....... 05 30 00 0B 10 40 01 02 1A 83 02 3F 00 85 01 01 .***@***.***?.... 86 09 FF FF FF FF FF FF FF FF FF 8A 01 05 CB 18 ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF ........ Sending: 00 A4 01 0C 02 11 00 Received (SW1=0x90, SW2=0x00) Sending: 00 A4 02 0C 02 11 01 Received (SW1=0x6A, SW2=0x82) Sending: 00 B0 00 00 00 Received (SW1=0x69, SW2=0x86) ``` ``` $ opensc-tool -s 00:A4:04:00:0C:A0:00:00:05:30:00:0B:10:40:01:02:1A:00 \ -s 00:A4:02:0C:02:2F:00 \ -s 00:B0:00:00:00 Using reader with a card: bit4id miniLector-EVO 00 00 Sending: 00 A4 04 00 0C A0 00 00 05 30 00 0B 10 40 01 02 1A 00 Received (SW1=0x90, SW2=0x00): 6F 46 81 02 70 2C 82 03 38 00 00 84 0C A0 00 00 oF..p,..8....... 05 30 00 0B 10 40 01 02 1A 83 02 3F 00 85 01 01 .***@***.***?.... 86 09 FF FF FF FF FF FF FF FF FF 8A 01 05 CB 18 ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF ........ Sending: 00 A4 02 0C 02 2F 00 Received (SW1=0x6A, SW2=0x82) Sending: 00 B0 00 00 00 Received (SW1=0x69, SW2=0x86) ``` Or maybe I didn't get something, since this is all new to me and I'm quite sleepy today. :-D

[ale-rinaldi]

Let's go straight to pcsc-spy then — and no need to install anything: we can pull the module straight out of the .deb and delete it when we're done.

1. Download and unpack the middleware (no install):

mkdir -p /tmp/cyb && cd /tmp/cyb
wget https://swdownload1.agenziaentrate.gov.it/pub/sanita/Cyberneid-Middleware_1.3.9.14_all.deb
dpkg-deb -x Cyberneid-Middleware_1.3.9.14_all.deb root

2. Start the spy (terminal 1, leave it running):

pcsc-spy

3. Read the certificate through the vendor module (terminal 2), preloading the spy so pcsc-spy logs every APDU:

MODULE=$(find /tmp/cyb/root -name 'libcybermw*.so*' | head -1)
SPY=$(find /usr/lib /lib -name 'libpcscspy.so*' 2>/dev/null | head -1)
LD_PRELOAD="$SPY" LD_LIBRARY_PATH="$(dirname "$MODULE")" pkcs11-tool --module "$MODULE" -O

-O lists the objects, which makes the module walk to the certificate — exactly the sequence we want. If -O doesn't reach the cert, force the read:

LD_PRELOAD="$SPY" LD_LIBRARY_PATH="$(dirname "$MODULE")" pkcs11-tool --module "$MODULE" --read-object --type cert --id 01 -o /tmp/cyb/cert.der

Paste the pcsc-spy output here (it's just card commands/responses, no personal data) and the cert path will be obvious — from there the itacns change is trivial.

4. Clean up — nothing was installed, so just:

rm -rf /tmp/cyb

(If the module complains it can't find a token or a config, the quickest fallback is to install the .deb with sudo dpkg -i, run the same read, then remove it with sudo dpkg -r. But the extract-only route usually works for reading the cert.)

[dengert]

This issue sounds very much like #3755 But there its the st2022 cards and the issue is more with contactless NFC. But both are Italian CNS cards

[ale-rinaldi]

@dengert you're right, and I actually suggested to open this one in a comment of the mentioned issue: #3755 (comment)

Similar issue, but different cards: unfortunately, for mostly historical issues, Italian CNSs are a mess :D I wrote about the topic here: OpenSC/Wiki#38

[dengert]

Nice writeup in the wiki.

Another OpenSC tool opensc-explorer might be helpful to look at the file structure on the card.

[dengert]

With opensc-explorer can you try something like this with your card. The example is a myeid PKCS15 card.

$ opensc-explorer
OpenSC Explorer version 0.26.1
Using reader with a card: Identiv SCR3500 A Contact Reader [CCID Interface] (54302140601290) 00 00
OpenSC [3F00]> ls
FileID	Type  Size
[5015]	  DF 32767	Name: \xA0\x00\x00\x00cPKCS-15
 2F00 	 wEF   128
OpenSC [3F00]> asn1 2f00
61 Application 1  (27 bytes)
   4F Application 15 (12 bytes)
      A0 00 00 00 63 50 4B 43 53 2D 31 35 ....cPKCS-15
   50 Application 16 (5 bytes): 4D 79 45 49 44 MyEID
   51 Application 17 (4 bytes): 3F 00 50 15 ?.P.
Zero tag, finishing

The 3F00 2F00 is the iso 7816-4 way of listing AID of applets on the card
It should show your AID
A0 00 00 05 30 00 0B 10 40 01 02 1A

Also note that the 3F00 has a DF of 5015 which is also in indicator it is a PKCS15 card
at least that is what OpenSC uses. But the 2F00 file also lists 3F 00 50 15

As @frankmorgner pointed out it appears that the "official" driver has some OpenSC code.
It might be that they are using a PKCS15 file structure.
You can use opensc-explorer to look around at the file structure.