The invoice is not signed: the signing key is not configured, cannot be read, is not valid or does not match

Symptom

When you click Confirm on an invoice (or another sales document), the Invalid Operation window appears saying the signing key is not configured, cannot be read, is not valid or that the private key does not match the version of the signing key. In every case, “Nothing was issued”. The invoice stays in Draft, with no number. It happens with any profile that issues invoices, on all of the company's invoices, until the problem is fixed on the server.

Every invoice issued by fiscaldoo is signed with the program's signing key. The key has two parts: the public one, stored in fiscaldoo, used to verify signatures; and the private one, stored in a file on the server, outside the database, used to sign. Both must be the same version.

Message

When the server's private key is from another version:

“The private key installed on this server does not match version 1 of the signing key, so documents cannot be signed (the signature could never be verified with this version). Nothing was issued. Contact the support: the system administrator has to install the private key of version 1, or register a new version of the signing key (key rotation) with the public key of the one installed.”

When the server has no private key:

“The signing key of the program is not configured on this server, so documents cannot be signed. Nothing was issued. Contact the support: the system administrator has to install the producer's key.”

When the server knows where the private key is, but the file is not there or cannot be read:

“The signing key of the program could not be read on this server, so documents cannot be signed. Nothing was issued. Contact the support: the system administrator has to check the key file.”

When the file exists, but what is inside it is not a key:

“The signing key of the program on this server is not valid, so documents cannot be signed. Nothing was issued. Contact the support: the system administrator has to install a valid key.”

The four messages were triggered in the demo database, with the Billing profile, when confirming a 147.60 € invoice to Clínica Dentária Sorriso, SA. The number in italics is the version of the company's key.

Verified causes

• The signing key changed version and the server kept the old file (or the other way round). A new key retires the previous one: the previous one stops signing, but still verifies the documents it signed. If the private key file does not follow the change, no document can be signed. In the demo, the key of Empresa Demonstração, Lda was at version 1 and the server was given the private key of another test key; the invoice was refused with the 1st message.
• The server has no private key. The server started without being told where the key is and found none. This is the typical case after changing server, reinstalling or restoring a copy without the key file. In the demo, started without that setting and with the file moved away, the invoice was refused with the 2nd message.
• The private key file is not where the server looks for it, or the server cannot read it. The server knows the location, but the file is not there or it has no permission to read it. In the demo, with a location set where there was no file, the invoice was refused with the 3rd message.
• The file does not hold a key. The file exists, but is damaged or is something else. In the demo, with a text file in place of the key, the invoice was refused with the 4th message.

The signing key has no end date: it does not “expire” with time. The certificates and keys that expire by date are those for communication with the AT (the Key vault and the Tax Authority credentials), which do not prevent invoices from being signed. Pending validation on screen: the messages for an expired communication certificate (for example “The key of company … expired on … and cannot be used”) cannot be triggered in the demo, which has a certificate valid until 29/10/2027.

What to check

1. The message: whether it talks about the key version (1st message), a key not configured (2nd), reading the file (3rd) or a key not valid (4th).
2. Whether the problem affects all of the company's invoices. Try to confirm another draft invoice: the refusal repeats.
3. Whether something changed on the server that day (update, restore of a backup, machine change, new key). This is what support will ask.

No company profile can fix this on screen: the private key file is on the server, outside fiscaldoo, and the signing key belongs to the program's producer.

How to fix it

On a production database

1. Do not keep retrying the same invoice or create invoices in another program to get round it: the problem affects every invoice. What the law provides for, if the outage goes past the issuing deadline, is further below.
2. Contact fiscaldoo support (or whoever manages the server) with the data from “Information to send”. Support installs the right private key on the server (for the 1st message, the one for the version it names).
3. Once support confirms, open the draft invoice and click Confirm again.

Invoices already issued do not change

Invoices issued before the problem can still be verified with the key version they were signed with, even after that version is retired. In the demo, after the key change, Settings › fiscaldoo · Certification › Verify integrity › Open answered “All good: the … documents checked have their signature, numbering and chain intact.”, including the documents signed with version 1, already retired. Do not cancel them or issue them again because of this message.

Who does it: support or the server administrator. The company confirms again when support says so.

If the outage goes past the issuing deadline

While the program does not sign, it does not issue invoices. The law provides for this case (Order (Despacho) no. 8632/2014, point 2.4, “Integration of documents processed manually on forms printed by authorised printers, when the program is inoperative”):

• the invoice is written by hand, on a form from an authorised printer;
• when the program works again, each manual document is integrated in its own recovery series, with an annual or longer periodicity and sequential numbering starting at no. 1 (point 2.4.1), in a new document of the same type with all the elements of the manual one (point 2.4.2) and with the date of the manual document (point 2.4.3).

The outage does not suspend the deadline for issuing the invoice (VAT Code (CIVA), art. 36, no. 1, para. a)). How to integrate the manual document in fiscaldoo is in The invoice cannot be dated before the last document of the series, in the case “The document was written by hand when the program was unavailable”. Pending validation by a certified accountant: from when the company should start issuing on authorised printer forms while the server does not sign, and what to do with receipts during that period.

On a test database

On a test database (the database name contains “test”), the Fiscal administration profile can generate a new test key in Settings › fiscaldoo · Certification › Configure the certification: series and keys › TEST signing key and software certificate › Generate. In the Generate TEST signing key window, choose in Company the company that gives the message. The server has a single private key file: companies that use another key keep the record of their version, but stop signing on this server. The option Also register a TEST software certificate? comes ticked.

In the demo:

• generating with Company empty retired the producer's key (version 1), created version 2 of the producer's key and swapped the server's file, and Empresa Demonstração, Lda, which has its own key, started giving the 1st message;
• generating with Company = Empresa Demonstração, Lda created version 3 for that company, and the next invoice was signed with it; the companies that used the producer's key could no longer sign.

A test key is never valid for a real document.

Who does it: Fiscal administration, only on a test database.

Expected result

• Confirm issues the invoice with the series' number and ATCUD. In the demo, after the right key was put back on the server, the refused invoice was confirmed as FT D26/35, just as FT D26/33 had been issued before the change.
• The journal entries are those of any invoice (in the example, 2111 Clientes gerais D 147.60 € / 721 Prestações de serviços C 120.00 € / 2433 IVA - Liquidado C 27.60 €). While the invoice is refused, nothing is posted.

When to contact support

• Whenever one of these messages appears on a production database.
• The message changed after support stepped in (for example, from “not configured” or “read” to “version”).

Information to send

• The full message, copied from the window (including the key version, if the message has it).
• The company and the time of the first refusal.
• The number of the last invoice issued before the problem.
• What changed on the server that day, if you know.