Rinnovare un certificato Sophos Firewall tramite API XML e verificare i servizi

La riduzione della durata dei certificati TLS pubblicamente attendibili aumenta l’impegno richiesto per i rinnovi manuali. Il certificato viene quindi emesso su un sistema esterno, importato da un host di automazione protetto, assegnato al servizio previsto e infine verificato sul listener reale. Un’emissione riuscita non conferma che l’importazione sia avvenuta; la presenza di un oggetto certificato non conferma quale certificato venga fornito da WebAdmin, Portal, WAF o SMTP.

I campi XML per add e update provengono sempre dalla API help della build SFOS in uso. Il campo identificativo di un oggetto esistente, il mantenimento dei riferimenti e il comportamento dopo gli errori vengono determinati con un test. Per questo motivo, l’articolo non mostra intenzionalmente un payload di aggiornamento che si pretenda universale.

La procedura in quattro fasi

Preparare: chiarire autorizzazioni della CA, convalide, host di automazione, accesso API e percorso di ripristino.
Testare: usando un nome di prova non critico, trasformare l’esempio locale di aggiunta/aggiornamento in una richiesta multipart legata alla versione e approvarla.
Rinnovare: verificare certificato e chiave, caricarli e assegnarli ai servizi previsti.
Convalidare: verificare il file dell’oggetto e il listener reale, monitorare il funzionamento e rimuovere il vecchio certificato solo in un secondo momento.

Perché le durate richiedono un’automazione robusta

La durata massima consentita per i certificati TLS pubblicamente attendibili si riduce gradualmente. Secondo i Baseline Requirements del CA/Browser Forum, per i certificati di nuova emissione valgono i seguenti limiti massimi:

prima del 15 marzo 2026: massimo 398 giorni;
dal 15 marzo 2026 al 14 marzo 2027: massimo 200 giorni;
dal 15 marzo 2027 al 14 marzo 2029: massimo 100 giorni;
dal 15 marzo 2029: massimo 47 giorni.

Anche il periodo consentito per riutilizzare convalide di dominio o IP già completate si riduce nelle stesse fasi, passando da 398 a 200, 100 e infine 10 giorni. Il certificato e la convalida su cui si basa hanno quindi scadenze separate.

Secondo il suo avviso aggiornato sulle durate più brevi, dal 24 febbraio 2026 DigiCert emette certificati TLS pubblici con una durata massima di 199 giorni. I limiti operativi di 99 e 46 giorni sono annunciati rispettivamente solo per l’inizio del 2027 e l’inizio del 2029; le date esatte della transizione potrebbero ancora cambiare. L’automazione monitora pertanto il valore notAfter del certificato effettivamente emesso, invece di presupporre una durata fissa di un anno.

Distinguere Let’s Encrypt integrato e CA esterna

La funzione Let’s Encrypt integrata in SFOS è una procedura autonoma gestita dal firewall. Non è un client ACME generico per DigiCert e non può essere semplicemente reindirizzata a un URL ACME DigiCert. Per la procedura integrata, il percorso corretto è Configurare certificati Let’s Encrypt su Sophos Firewall.

Con una CA pubblica esterna, l’emissione avviene su un sistema adatto allo scopo. Solo il certificato emesso viene successivamente trasferito a SFOS tramite l’API XML.

Individuare i prerequisiti indipendenti dalla CA

Prima della configurazione, occorre chiarire i seguenti punti con la CA scelta:

autorizzazione al prodotto e tipi di certificato consentiti;
ordine, abbonamento o altra modalità di pagamento;
creazione, validità e rotazione delle credenziali ACME o API;
metodo DCV supportato per ogni nome ordinato;
convalida dell’organizzazione necessaria per OV/EV;
scadenze del certificato, della convalida del dominio e della convalida dell’organizzazione.

Le denominazioni e i passaggi di approvazione variano in base al fornitore. I dettagli dell’account riportati di seguito sono quindi un esempio concreto relativo a DigiCert, non un requisito generale delle CA.

Esempio DigiCert: preparare account e ACME

In CertCentral, la funzione di automazione deve essere attivata per l’account interessato. La configurazione e l’approvazione dipendono poi dal modello di account:

Per gli account Enterprise, Partner e gli account meno recenti senza abbonamento, solo un amministratore CertCentral può creare l’ACME Directory URL. Può quindi consegnare le credenziali complete a un account di servizio con autorizzazioni minime per il normale funzionamento.
Per gli account Enterprise e gli altri account senza abbonamento, deve essere attivata l’approvazione automatica delle richieste di certificato; senza questa impostazione, le richieste ACME non riescono per impostazione predefinita.
Gli account Subscription non richiedono questa impostazione per l’approvazione automatica delle richieste. I prodotti disponibili e lo stato dell’abbonamento devono comunque essere adeguati.

In questo modo, le autorizzazioni estese necessarie per creare le credenziali restano separate dall’account di automazione utilizzato in seguito. Prima del primo ordine, verificare inoltre l’autorizzazione al prodotto, la modalità di pagamento e l’associazione dell’ACME Directory URL e dell’External Account Binding all’account e al prodotto corretti. Una persona chiaramente responsabile gestisce la creazione, la rotazione e la sostituzione di emergenza delle credenziali.

Le credenziali ACME devono essere conservate in un archivio segreto protetto. Non devono essere scritte in un repository, uno script shell, un ticket, un esempio wiki o un’esportazione Postman.

Esempio DigiCert: DCV per DV, OV ed EV

Per un certificato DV, DigiCert esegue nuovamente la Domain Control Validation per ogni ordine ACME; una DCV precedente non viene preconvalidata né riutilizzata. L’host di automazione deve poter completare la challenge scelta a ogni rinnovo.

Per i certificati OV ed EV, l’emissione ACME non presidiata richiede un’organizzazione convalidata in precedenza. Anche lo stato del dominio deve essere valido. Attualmente DigiCert utilizza una convalida del dominio OV/EV riutilizzabile per 199 giorni; la convalida dell’organizzazione per i certificati OV pubblici è attualmente riutilizzabile per 397 giorni. Entrambe le scadenze vengono monitorate separatamente dalla scadenza del certificato.

Per un certificato wildcard come *.example.com, DNS-01 è il metodo di convalida tipico. L’accesso all’API DNS dovrebbe consentire di modificare solo la zona o il record necessario.

Configurare un host di automazione sicuro

L’host di automazione gestisce temporaneamente la chiave privata, le credenziali della CA e una password SFOS con autorizzazione di scrittura. Deve trovarsi in un ambiente di gestione protetto, non su un comune notebook amministrativo o in un ambiente di esecuzione CI qualsiasi.

I requisiti minimi sono:

sistema operativo aggiornato e con hardening, affidato a una persona chiaramente responsabile;
IP sorgente fisso o rete di gestione strettamente limitata;
accesso in uscita limitato a CA, API DNS e firewall previsti;
credenziali separate per CA, DNS e ogni firewall, oppure per un gruppo di firewall chiaramente delimitato;
archivio segreto anziché variabili d’ambiente, output diagnostici, parametri della riga di comando o file di testo in chiaro;
autorizzazioni restrittive sui file e directory di lavoro temporanea su storage cifrato;
nessuna chiave privata, password o richiesta XML completa nei log;
ID dell’ordine, firewall di destinazione, nome del certificato e risultato tracciabili, senza contenuti segreti;
sincronizzazione dell’ora e avviso in caso di errori ripetuti o durata residua troppo breve.

Se la chiave privata viene trasferita a SFOS in forma cifrata, per ragioni di compatibilità la password di importazione non dovrebbe superare i 30 caratteri. La guida della GUI SFOS indica questo limite massimo, mentre la guida API descrive, a seconda della build, da 4 a 128 caratteri. Il limite di 30 caratteri serve esclusivamente alla compatibilità e non è una raccomandazione generale sulla lunghezza delle password. La password casuale vale solo per questa chiave e viene trasmessa in modo protetto.

La protezione di sorgente, account di servizio, Device Access e autorizzazioni API è descritta in Proteggere l’accesso all’API XML di Sophos Firewall. In SFOS 22, in Administration > API access viene consentito solo l’IP Host del sistema di automazione sotto Allowed IP hosts. Nelle versioni precedenti, la configurazione API si trova in un altro percorso di menu.

Test prima del rinnovo in produzione

Il test utilizza un nome di prova non critico come test-fw.example.com, un oggetto certificato separato e un listener per il quale un’interruzione sia accettabile. Viene ripetuto dopo aggiornamenti significativi di SFOS o dell’automazione.

Determinare il comportamento della build in uso

I test determinano il comportamento della build specifica; non sostituiscono una garanzia del produttore. È necessario verificare e registrare:

build SFOS esatta e API help locale utilizzata;
campi add e update esatti e campo identificativo dell’oggetto esistente;
risultato del reinvio della stessa richiesta e comportamento dopo un upload interrotto;
elaborazione di un file di certificato con certificato leaf e certificati Intermediate, nonché gli oggetti CA risultanti;
catena effettivamente fornita;
mantenimento o perdita dei riferimenti WebAdmin, Portal, WAF e SMTP;
necessità di attivare il listener o di riavviare un servizio;
in HA, trasferimento di certificato, chiave privata e assegnazione, nonché il certificato fornito dopo un failover.

Un file fullchain non va considerato supportato senza averlo verificato. Analogamente, l’automazione non deve presupporre l’idempotenza, il mantenimento dei riferimenti o la possibilità di ripetere automaticamente e in sicurezza un’operazione dopo un errore.

Dall’esempio locale di aggiunta/aggiornamento alla richiesta

In questo modo si crea una richiesta concreta per la build installata, senza presentarla erroneamente come universale:

Nella API help locale del firewall di destinazione, passare a System > Certificates > Certificate > Add Certificate / Update Certificate. Salvare la configurazione di esempio e la descrizione dei parametri per questa specifica build.
Per il primo caso, usare il wrapper add documentato. Per il secondo, adottare l’update mostrato nella guida e il relativo campo identificativo. Non copiare né l’attributo dell’operazione né l’identificativo dell’oggetto da un’altra build.
Nell’esempio, sostituire solo i valori dell’ambiente: credenziali API provenienti dall’archivio segreto, nome oggetto test-public-cert, azione per l’upload del certificato, formato del certificato, nome del file del certificato, nome del file della chiave privata ed eventualmente password di importazione. Rimuovere i rami dell’esempio non necessari, ma lasciare invariati i nomi e l’annidamento degli elementi.
Generare localmente la richiesta XML risultante come reqxml temporaneo. I due nomi file nell’XML devono corrispondere esattamente ai file caricati.
In Postman o nella libreria HTTP utilizzata, inviare una richiesta POST al seguente endpoint e scegliere multipart/form-data:
```
https://<Firewall-FQDN>:<Admin-Port>/webconsole/APIController
```
Creare esattamente tre parti multipart: la parte file indicata nella guida locale per il certificato, la parte file indicata per la chiave privata e il campo di testo reqxml. I nomi delle prime due parti non vanno dedotti: il loro nome corrente e i nomi file vengono ripresi dall’esempio della build di destinazione.
Eseguire prima add, poi update con un certificato di test emesso nuovamente. Inviare inoltre una richiesta non valida nell’ambiente di test e rileggere lo stato prima di ripetere l’operazione.
La richiesta viene approvata solo quando <Response> e <Status> indicano il successo atteso, è stato modificato esattamente l’oggetto previsto, non sono stati creati oggetti CA imprevisti, il riferimento del servizio si comporta come registrato e, dopo l’assegnazione, il listener esterno fornisce il nuovo certificato con una catena valida. In HA è incluso un failover controllato.

In base ai risultati, la richiesta viene creata, testata e approvata internamente per quella specifica build. I tre nomi delle parti, il modello XML, i valori di stato attesi e le condizioni di interruzione vengono versionati insieme, senza memorizzare credenziali o chiavi.

Verificare il certificato prima dell’upload

Gli esempi seguenti utilizzano questi valori sostitutivi:

FQDN del servizio: vpn.example.com
nome oggetto SFOS: public-vpn-example-com
certificato leaf: vpn.example.com.pem
chiave privata: vpn.example.com.key
bundle Intermediate: intermediates.pem
bundle Root attendibili: trust-roots.pem
porta HTTPS esterna: 443

Per prima cosa, leggere i dati del certificato:

openssl x509 -in vpn.example.com.pem -noout -subject -issuer -serial -dates -ext subjectAltName -fingerprint -sha256

Emittente, periodo di validità, SAN e fingerprint SHA-256 devono corrispondere all’ordine. Verificare quindi che il certificato e la chiave privata appartengano alla stessa coppia di chiavi, senza visualizzare la chiave:

(
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl x509 -in vpn.example.com.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
    openssl pkey -in vpn.example.com.key -pubout > "$tmpdir/key-public-key.pem" &&
    cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

Se le chiavi pubbliche sono identiche, cmp non produce alcun output. In caso di differenza, la procedura si interrompe. Per una chiave privata cifrata, la password viene richiesta in modo interattivo; nell’automazione proviene dall’archivio segreto e non compare né nell’invocazione del processo né nel log.

La catena prevista viene verificata rispetto al proprio trust store:

openssl verify -CAfile trust-roots.pem -untrusted intermediates.pem vpn.example.com.pem

trust-roots.pem contiene le Root CA considerate attendibili nel proprio ambiente, mentre intermediates.pem contiene le Intermediate CA associate all’emissione. La verifica riesce solo se restituisce vpn.example.com.pem: OK; qualsiasi altro output interrompe l’upload.

Trasferire il certificato tramite API XML

Verifiche prima dell’upload

Prima della scrittura, confrontare firewall di destinazione, build SFOS, nome oggetto e servizi con la modifica approvata. Devono essere disponibili un backup aggiornato di Sophos Firewall, l’accesso di gestione alternativo e l’oggetto certificato precedente. Dallo stesso host e con lo stesso account di servizio, eseguire innanzitutto una richiesta di lettura innocua. Le autorizzazioni sui file e le verifiche locali del certificato non devono mostrare errori.

Inviare la richiesta e valutare la risposta

L’automazione invia la richiesta multipart approvata durante il test. Il certificato e la chiave privata vengono trasferiti come file; reqxml viene generato durante l’esecuzione e poi eliminato. Il client utilizza l’FQDN corrispondente al certificato del firewall, ne convalida la CA e si interrompe in caso di errori del nome host o del certificato. Non è consentito usare curl -k o disattivare in modo analogo la verifica TLS.

Uno stato HTTP 200 o Send successful conferma solo il trasporto. L’automazione valuta nell’XML almeno l’elemento <Response> associato all’operazione e il relativo <Status> in base ai valori approvati durante il test. In caso di timeout, risposta incompleta o stato negativo, prima rilegge lo stato dell’oggetto oppure si interrompe per consentire una verifica manuale; non ripete la richiesta di scrittura senza controlli.

Controllare l’oggetto e il file scaricato

In Certificates > Certificates, cercare l’oggetto di destinazione. Nella GUI si verificano i dati effettivamente disponibili, in particolare nome dell’oggetto, stato della chiave privata, Trusted, i valori Subject, Issuer e Purpose visibili al passaggio del puntatore, nonché eventuali oggetti certificato o CA aggiuntivi e imprevisti.

Numero di serie, SAN, data di scadenza e fingerprint SHA-256 non sono considerati campi garantiti della GUI. Esportare il certificato di destinazione tramite l’azione di download di SFOS e verificare il file scaricato:

openssl x509 -in downloaded-vpn.example.com.pem -noout -serial -dates -issuer -subject -ext subjectAltName -fingerprint -sha256

Questi valori devono corrispondere al file verificato prima dell’upload. Il solo stato verde Trusted non dimostra né la corretta assegnazione al servizio né la completezza della catena del listener. Formati, catena e importazione tramite GUI sono illustrati in Importare e assegnare certificati su Sophos Firewall.

Assegnare il certificato al servizio

L’importazione e l’assegnazione sono modifiche separate. Un nuovo oggetto viene assegnato esplicitamente al servizio desiderato. In caso di aggiornamento, si usa il percorso confermato durante il test e, al termine, si controlla l’effettivo mantenimento dei riferimenti.

WebAdmin e portali

In Administration > Admin and user settings > Admin console and end-user interaction, il campo Certificate vale congiuntamente per WebAdmin Console, User Portal, VPN Portal, Captive Portal, SPX Registration e Reply Portal. Il certificato deve contenere come SAN tutti i nomi effettivamente utilizzati. Dopo Apply, verificare separatamente ogni FQDN e porta; mantenere aperti una sessione amministrativa esistente e un percorso alternativo di gestione locale.

WAF

Per una pubblicazione WAF, il certificato viene selezionato nella rispettiva regola, in Rules and policies > Firewall, nel campo HTTPS certificate. Dominio, SNI, Listen Port e SAN devono corrispondere. Al salvataggio, le regole di Web Server Protection vengono riavviate; le connessioni esistenti possono interrompersi. Occorre verificare durante il test, con la build in uso, se anche la sostituzione di un certificato già referenziato provochi un reload.

SMTP TLS

In modalità MTA, la selezione si trova in Email > General settings > SMTP TLS configuration, nel campo TLS certificate. Dopo Apply, STARTTLS ed eventualmente TLS implicito vengono verificati separatamente. VPN e altri utilizzi dei certificati possono avere assegnazioni proprie; un nome identico non implica che vengano aggiornati automaticamente.

Convalidare esternamente con SNI e la porta corretta

Per prima cosa, controllare catena e nome host da un host di verifica esterno realistico:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts -verify_hostname vpn.example.com -verify_return_error </dev/null

Sono attesi i certificati Intermediate necessari e Verification: OK. -servername invia SNI; FQDN e porta vanno sostituiti con quelli del servizio reale.

Fingerprint, numero di serie e altri dati del certificato leaf possono essere letti con un secondo passaggio eseguibile dalla stessa configurazione del listener:

(
  set -o pipefail
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts \
    -verify_hostname vpn.example.com -verify_return_error </dev/null 2>"$tmpdir/s_client.log" |
    openssl x509 -out "$tmpdir/leaf.pem" &&
  openssl x509 -in "$tmpdir/leaf.pem" -noout -serial -fingerprint -sha256 -dates -issuer -subject -ext subjectAltName
)

Numero di serie, fingerprint SHA-256, durata, Issuer e SAN devono corrispondere al certificato approvato. Successivamente, verificare l’applicazione stessa, ad esempio eseguendo l’accesso al portale, un health check WAF o un’altra funzione end-to-end priva di rischi. Un load balancer, CDN o reverse proxy a monte potrebbe terminare TLS con un altro certificato; il punto di test deve pertanto corrispondere alla funzione SFOS prevista.

SMTP con STARTTLS richiede un comando separato:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Per TLS implicito sulla porta 465, omettere -starttls smtp. Anche in questo caso, catena e nome host vengono confermati da Verification: OK; i dati del certificato leaf possono essere letti usando il modello di estrazione precedente con le opzioni di connessione adattate. Verificare quindi il flusso di posta effettivo.

Finestra di manutenzione, rollback e HA

Preparare la finestra di manutenzione

La prima esecuzione in produzione e le modifiche alla richiesta, alla build SFOS, al prodotto CA o alla composizione della catena avvengono in una finestra di manutenzione. L’oggetto precedente rimane disponibile; sono note le assegnazioni interessate, l’accesso di gestione alternativo e le persone responsabili del ripristino e della verifica esterna.

Scegliere la strategia di rollback

Per un nuovo oggetto, il percorso di ripristino più chiaro consiste nel selezionare nuovamente il vecchio certificato nel servizio interessato e ripetere il test esterno del listener. Per questo motivo, il vecchio oggetto non viene eliminato durante la stessa esecuzione.

Quando si aggiorna l’oggetto esistente, è valido esclusivamente il percorso di ripristino confermato durante il test. Se non è stata dimostrata la possibilità di ripristinare in sicurezza il contenuto precedente, si adotta un approccio conservativo: si crea un nuovo oggetto separato e lo si assegna poi esplicitamente.

Testare HA separatamente

In linea di principio, in un cluster HA SFOS sincronizza la configurazione dal Primary all’Auxiliary. Certificato, chiave privata e assegnazione al servizio devono comunque essere verificati su entrambi i nodi o sul servizio condiviso. Segue quindi un failover controllato con verifica esterna del listener. Solo il superamento del test consente di approvare la procedura per HA.

Monitoraggio e attività ricorrenti

L’automazione deve segnalare tempestivamente errori e rinnovi mancati. Vengono monitorati continuamente:

giorni residui del certificato sul listener esterno e successiva finestra di rinnovo della CA;
stato DCV e, per OV/EV, anche convalida dell’organizzazione;
ultimo ordine CA e ultimo upload SFOS riusciti;
fingerprint previsto ed effettivamente fornito;
errori API, risposte ambigue ed esecuzioni interrotte;
nuovi oggetti certificato o CA non pianificati;
scadenza e rotazione delle credenziali;
in HA, ultimo test di failover superato.

L’avviso deve lasciare tempo sufficiente per la durata delle procedure CA/DCV, la reazione interna, la finestra di manutenzione e il ripristino. Dopo una sostituzione riuscita, il vecchio certificato resta disponibile durante il periodo di osservazione definito. I file temporanei di certificato, chiave e XML vengono eliminati in modo controllato; le evidenze archiviate in modo permanente contengono solo metadati non segreti.

Risoluzione dei problemi in base al sintomo

La CA non emette un nuovo certificato

Verificare presso il rispettivo fornitore autorizzazione al prodotto, stato dell’account, modalità di pagamento e DCV. Nell’esempio DigiCert, controllare inoltre l’automazione e l’approvazione automatica delle richieste specifica per il modello di account. Per OV/EV, organizzazione e dominio devono essere validi. Controllare gli errori DNS-01 sul DNS pubblico autorevole, non solo sul resolver locale.

L’API XML non è raggiungibile

Verificare l’IP sorgente dal punto di vista del firewall, Allowed IP hosts, Device Access, routing, porta amministrativa e certificato del firewall. Il test deve essere eseguito dall’host di automazione reale.

La richiesta HTTP riesce, ma il certificato non viene aggiornato

Controllare <Response> e <Status>, non soltanto il codice HTTP. Confrontare quindi nome oggetto, formato file, lunghezza consentita della password e campi specifici della build con la guida API locale. In Diagnostics > Troubleshooting logs sono utili apiparser.log, validation.log e validationError.log; rimuovere tutte le credenziali prima di condividere i log. Se lo stato non è chiaro, scaricare e verificare innanzitutto l’oggetto certificato, invece di ripetere la richiesta di scrittura senza controlli.

L’oggetto è nuovo, ma il servizio mostra ancora il vecchio certificato

Verificare assegnazione al servizio, regola WAF, selezione condivisa del certificato per WebAdmin e portali oppure configurazione SMTP. Eseguire quindi il test con SNI sulla porta corretta ed escludere la presenza di un endpoint TLS a monte.

Il certificato non è `Trusted` o la catena è incompleta

Confrontare l’Issuer del certificato leaf con le Intermediate CA installate. Usare il metodo di importazione confermato durante il test e controllare con -showcerts la catena inviata dal listener.

Dopo un aggiornamento o un failover riappare il vecchio certificato

Determinare quale nodo e listener risponde. Confrontare quindi fingerprint dell’oggetto scaricato, riferimento del servizio e stato HA. In caso di differenze, eseguire il percorso di ripristino confermato e arrestare l’automazione.

Checklist di accettazione

Il rinnovo in produzione viene approvato solo se sono soddisfatti tutti i punti:

Autorizzazione della CA, pagamento, DCV ed eventualmente convalida dell’organizzazione sono validi.
Build, guida API locale e richiesta multipart corrispondono al test superato.
La verifica locale di certificato, chiave e catena è riuscita.
<Response> e <Status> indicano il successo atteso; è stato modificato esattamente l’oggetto di destinazione.
Il file dell’oggetto scaricato presenta numero di serie, SAN, durata e fingerprint SHA-256 attesi; la chiave privata e lo stato Trusted sono corretti e non sono stati creati oggetti imprevisti.
Ogni combinazione reale di FQDN e porta fornisce con SNI il nuovo certificato, la catena attesa e Verification: OK; il servizio associato funziona.
In HA, il failover controllato con verifica esterna è stato superato.
Il monitoraggio rileva la nuova data di scadenza e il risultato positivo; il vecchio certificato rimane disponibile come percorso di ripristino fino alla fine del periodo di osservazione.