Help

AutoFirma on Mac: why it fails and where DNIe for Mac fits

Guide updated: 28 July 2026 · by David Pelayo (nexoapex)

AutoFirma is the Spanish government's official e-signature application, and many government sites invoke it directly to sign a submission. DNIe for Mac doesn't force it out: it's interoperable with AutoFirma, and it separately handles browser sign-in and standalone document signing on its own, without leaving your Mac. If you came here because AutoFirma isn't working, jump straight to the most common macOS failures.

What is AutoFirma?

AutoFirma is the e-signature client distributed free of charge by the Government of Spain. Many Spanish e-government sites (Agencia Tributaria, Social Security, DGT and others) invoke it from the browser when a submission needs to be signed on the spot. DNIe for Mac is not AutoFirma or an official substitute for it: it's an independent application by nexoapex that reads your DNIe, signs you in and signs documents on its own.

AutoFirma isn't working on your Mac: the most common failures

These are the usual reasons AutoFirma fails on macOS, and how to tell whether the problem is AutoFirma itself, your card reader, or the DNIe card. For faults in AutoFirma proper, the authoritative source is its official site; what follows helps you locate where the problem actually is.

macOS won't let AutoFirma open ("developer cannot be verified")

That's Gatekeeper, macOS's app control, not a bug in the program. Right-click the app and choose Open, or go to System Settings → Privacy & Security and click Open Anyway in the notice that appears right after the attempt. Always download AutoFirma from the government's official site, never from a third-party mirror.

AutoFirma doesn't show your DNIe certificate

This is the most common failure on Mac, and there are three layers to rule out in order: that macOS recognizes the reader, that the card can be read, and that the certificate store AutoFirma uses can see the DNIe. To separate the first two from the third: if DNIe for Mac reads your card and shows your data and the state of your certificates, the reader and the card are fine and what's left is AutoFirma configuration. If it can't see them either, the problem is upstream — the reader or the card.

Your Mac doesn't recognize the card reader

Contact readers that follow CCID work on macOS with no drivers to install. Check under Apple menu → About This Mac → More Info → System Report → USB: the reader must appear in the list. If it doesn't, try another port or cable and avoid unpowered hubs. Insert the card chip-first, all the way in. If you are choosing a reader, or unsure whether yours will do, the full guide is which DNIe card readers work on a Mac.

macOS sees the reader but AutoFirma says there is none

Worth separating from the case above: the reader is fine and macOS recognizes it, but the Java runtime bundled inside AutoFirma never reaches it, and the app logs "no card readers detected on the system" or a card-not-present error. To confirm macOS sees it, run system_profiler SPSmartCardsDataType in Terminal: your reader must appear under Readers.

If it does and AutoFirma still doesn't see it, the fault is neither your reader nor the card, and no hardware setting will fix it: it belongs to AutoFirma, and the fix belongs to firmaelectronica.gob.es. DNIe for Mac doesn't go through Java: it talks to the reader through CryptoTokenKit, the macOS smart card layer.

AutoFirma throws a Java error

Current AutoFirma builds for macOS ship their own Java runtime, so reinstalling the current version from the official site usually clears Java errors inherited from an older install that relied on a system Java. DNIe for Mac uses no Java at all — it is a native macOS app.

AutoFirma won't open on an Apple Silicon Mac (M1, M2, M3)

AutoFirma ships in two Mac builds, one for Intel and one for Apple Silicon. Depending on which one you install, macOS may ask for Rosetta 2 to run Intel-compiled components; if the app never opens, install it from Terminal with softwareupdate --install-rosetta and try again. DNIe for Mac is a universal app: on Apple Silicon it runs natively and needs no Rosetta.

The browser launches AutoFirma, then says it can't reach it

This is the most repeated failure after the certificate one. The government site opens an afirma:// link, AutoFirma starts in the background and raises a small local server; the browser then has to connect to it over wss://127.0.0.1 using an SSL certificate that the AutoFirma installer generates on your Mac and adds to the keychain. If that certificate is missing or untrusted, the browser drops the connection and you get "could not contact AutoFirma" even though the app is open.

What works for most people is AutoFirma's own repair function: Tools → Restore installation. If that doesn't complete, install the certificates by hand: open ~/Library/Application Support/AutoFirma, double-click AutoFirma_ROOT.cer and autofirma.cer, then in Keychain Access → System → Certificates set both to Always Trust (the second one shows up as "127.0.0.1" or as "localhost", depending on the install). Don't go looking for a fixed port such as 8080: AutoFirma opens dynamic ports and they change on every attempt.

AutoFirma reports error SAF_45 ("could not open a socket")

Same scenario, seen from AutoFirma's side: the app starts but can't raise its local server, because it can't read the key store it uses to encrypt that connection. On macOS this has been traced to the installer leaving ~/Library/Application Support/AutoFirma owned by root, so your own user can't open it.

Check it in Terminal with ls -ld ~/Library/Application\ Support/AutoFirma. If the owner is root, hand it back to your user with sudo chown -R "$(whoami):staff" ~/Library/Application\ Support/AutoFirma and retry the submission. AutoFirma's own log, at ~/.afirma/AUTOFIRMA.afirma.log.xml, records the failed socket right before the SAF_45.

AutoFirma stops opening after you restart the Mac

This happens when you install a new version on top of an older one. The macOS disk isn't case-sensitive, so AutoFirma.app and Autofirma.app are the same folder and the installer can merge both versions, leaving stale files that don't match the new code signature. It keeps working until you restart; after that macOS refuses it and says the app can't be opened.

Check it in Terminal with codesign -vv /Applications/AutoFirma.app: if it answers "a sealed resource is missing or invalid", the bundle is merged. The way out is to drag the app to the Trash, empty it, and install again from the official site without keeping the previous install.

AutoFirma 1.9 and 1.9.1 could leave the login keychain unusable

On macOS 26.4 and 26.4.1, installing or restoring those versions could render the login keychain inaccessible: the system starts asking for its password and rejecting it, and after a restart you get a new, empty keychain. The old one stays in ~/Library/Keychains with "rename" added to its name, but no longer opens. It was fixed in AutoFirma 1.9.2 and in macOS 26.5, so install 1.9.2 or later, not the earlier ones.

What you lose are the stored passwords and any software certificates that lived in that keychain; if you have Time Machine, restoring ~/Library/Keychains/login.keychain-db from an earlier backup usually brings them back. DNIe certificates aren't there: they live on the card's chip, so a damaged keychain doesn't take them with it, and they're available again as soon as you plug in the reader with the card in it.

The certificate is in the keychain, but AutoFirma doesn't list it

This affects software certificates installed in the keychain — DNIe certificates are on the card, not there. With AutoFirma 1.8.3 and 1.8.4 it was confirmed that marking the certificate as Always Trust in Keychain Access makes the Java shipped with those versions stop seeing it; setting it back to Use System Defaults in the Trust panel brings it back.

To tell whether the problem is the certificate or AutoFirma, run security find-identity -v in Terminal: it lists only certificates that still have their private key and can therefore sign. If yours isn't there, it won't sign in any application. DNIe for Mac doesn't handle software certificates such as FNMT ones: it works with the DNIe certificates, which are on the card.

The DNIe certificate has expired, or the PIN is blocked

Then it isn't AutoFirma: no application can sign with an expired certificate or a blocked PIN, and the DNIe has no PUK. Both are fixed in person, free and without an appointment, at a DNIe Update Point (PAD). Step by step in our blocked or expired PIN guide.

Does DNIe for Mac replace AutoFirma?

No. Sites that invoke AutoFirma directly to sign a submission still need it — that doesn't change. What DNIe for Mac offers is interoperability with AutoFirma — it doesn't interfere with it, and you can have both installed on the same Mac — plus it independently handles two things that don't always require AutoFirma: signing in to a browser session, and signing a document that isn't part of a government-site submission flow.

When you use which

AutoFirma and DNIe for Mac, side by side

The AutoFirma row summarizes its public role and cost; for its full feature set, see the official source at firmaelectronica.gob.es.

Do I need to install Java for any of this?

Not for DNIe for Mac: it's a native macOS application, with no Java, no system configuration and no profiles. You only need macOS 13 or later (Intel or Apple Silicon), a USB contact card reader, your DNIe and your PIN.

What about Firefox?

Firefox doesn't use the native macOS integration (CryptoTokenKit) that Safari, Chrome and Edge rely on. That's why DNIe for Mac ships its own PKCS#11 module, available in the direct-download edition (coming soon), so your DNIe certificate shows up in Firefox too.

More on what DNIe for Mac does or how to get it. If you're looking for help with a blocked PIN or an expired certificate, see the blocked or expired PIN guide.