certificate_expired

HTTP 400   type: validation_error   param: device_id (fiscalizing) or file (uploading)

{
  "error": {
    "type": "validation_error",
    "code": "certificate_expired",
    "message": "The signing certificate for AWAIT 8 J.D.O.O. expired on 2026-03-01. Every device of this company is blocked until a current certificate is uploaded.",
    "param": "device_id",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/certificate_expired"
  }
}

What happened

The company’s certificate is outside its validity window. Either it lapsed while in use, or you tried to upload one that is already expired.

FiskHub refuses to sign with it rather than sending a message the Tax Administration would reject with s002.

This blocks the whole company at once

Certificates are per company. When one expires, every device belonging to that company stops being able to fiscalize simultaneously — every machine, every site, from the same minute.

It is the single change most likely to take a whole estate offline, and it happens on a date known months in advance.

Should you retry?

No. The certificate will not become valid again.

The fix

Upload a current certificate. There is no downtime and nothing else changes — the new one supersedes the old one the moment it is accepted.

curl -sS -X POST https://api.fiskhub.com/v1/certificates \
  -H "Authorization: Bearer $FISKHUB_API_KEY" \
  -F "company_id=3a5f2b18-7c4d-4e91-9a2b-6d8e0f1c3a57" \
  -F "[email protected];type=application/x-pkcs12" \
  -F "passphrase=$P12_PASSPHRASE" \
  -F "label=FISKAL 1 (2027)"

The subject OIB must still equal the company’s OIB.

Fiscalization resumes on the next request. Sales stored on the machines while they were blocked can be submitted with their original occurred_at — FiskHub marks them as late delivery.

The 30-day deadline is still running

A sale more than 30 days old is rejected permanently. An expiry noticed a month late means the earliest stored sales may already be unrecoverable. Upload the new certificate and flush the backlog on the same day.

Preventing it

days_until_expiry is on every certificate:

curl -sS -G https://api.fiskhub.com/v1/certificates \
  -H "Authorization: Bearer $FISKHUB_API_KEY" \
  --data-urlencode "company_id=3a5f2b18-7c4d-4e91-9a2b-6d8e0f1c3a57"

FiskHub sends notices at 60, 30, 14, 7 and 1 days, and certificate_status on the company moves to expiring below 60 days. Reading either into your own monitoring costs ten minutes and prevents a fleet-wide outage.

Renewal takes time — a certificate is issued by a provider, not by us — so start at the 60-day notice rather than the 7-day one.

Choosing a replacement

Date	Change
01.05.2026	eIDAS trusted-list certificates accepted
31.12.2026	PROD stops accepting RSA-SHA1
01.01.2027	PROD rejects TLS 1.1

FiskHub signs with RSA-SHA256 already, so the December 2026 change needs nothing from you. It matters when choosing the replacement: make sure it is one an RSA-SHA256 signature can be built from.