{"id":1451,"date":"2026-03-06T19:07:50","date_gmt":"2026-03-06T18:07:50","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/automatizzare-rinnovo-certificati-ssl-certbot-acme-sh-lets-encrypt\/"},"modified":"2026-03-06T19:07:50","modified_gmt":"2026-03-06T18:07:50","slug":"automatizzare-rinnovo-certificati-ssl-certbot-acme-sh-lets-encrypt","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/automatizzare-rinnovo-certificati-ssl-certbot-acme-sh-lets-encrypt\/","title":{"rendered":"Come Automatizzo il Rinnovo dei Certificati SSL\/TLS con Certbot, ACME.sh e Let&#8217;s Encrypt: La Mia Guida Pratica"},"content":{"rendered":"<p>Se gestisci server come faccio io da anni, sai benissimo che un <strong>certificato SSL\/TLS scaduto<\/strong> \u00e8 uno degli incubi peggiori: il sito va in errore, gli utenti vedono l&#8217;avviso &#8220;La connessione non \u00e8 sicura&#8221;, le conversioni crollano e Google ti penalizza nel ranking. Ho vissuto questa situazione una volta sola \u2014 e mi \u00e8 bastata per automatizzare tutto in modo che non succedesse mai pi\u00f9.<\/p>\n<p>Nel 2026 il tema dell&#8217;<strong>automazione dei certificati SSL<\/strong> \u00e8 pi\u00f9 attuale che mai: Let&#8217;s Encrypt ha annunciato la riduzione progressiva della validit\u00e0 dei certificati da 90 a 45 giorni, ha introdotto certificati <em>short-lived<\/em> da 6 giorni, e sta deprecando il supporto a <em>TLS Client Authentication<\/em>. Se non hai un sistema di rinnovo automatico affidabile, ti aspettano notti insonni. In questa guida vi mostro come ho configurato l&#8217;intera pipeline di automazione SSL sui miei server Linux usando <strong>Certbot<\/strong>, <strong>acme.sh<\/strong> e <strong>Let&#8217;s Encrypt<\/strong>, con tutti i comandi testati e funzionanti.<\/p>\n<p>Se ti occupi anche di sicurezza WordPress, ti consiglio di leggere il mio articolo su <a href=\"https:\/\/darioiannascoli.it\/blog\/protezione-wordpress-vulnerabilita-plugin-virtual-patching-patchstack-waf-monitoraggio-cve\/\">come proteggo WordPress dalle vulnerabilit\u00e0 plugin con virtual patching e WAF<\/a>, perch\u00e9 un certificato SSL valido \u00e8 solo il primo livello di difesa.<\/p>\n<h2>Cosa Cambia nel 2026: Le Novit\u00e0 Let&#8217;s Encrypt che Devi Conoscere<\/h2>\n<p>Prima di entrare nella parte pratica, \u00e8 fondamentale capire cosa sta succedendo nel mondo dei <strong>certificati SSL\/TLS<\/strong> nel 2026, perch\u00e9 queste novit\u00e0 impattano direttamente sulla tua strategia di automazione.<\/p>\n<h3>Riduzione della Validit\u00e0 dei Certificati: Da 90 a 45 Giorni<\/h3>\n<p>Let&#8217;s Encrypt, in conformit\u00e0 con le nuove regole del <em>CA\/Browser Forum Baseline Requirements<\/em>, sta riducendo gradualmente la validit\u00e0 dei certificati. Ecco la timeline che ho annotato:<\/p>\n<ul>\n<li><strong>Maggio 2026:<\/strong> il profilo ACME <em>tlsserver<\/em> passa a certificati da 45 giorni (opt-in per early adopter)<\/li>\n<li><strong>Febbraio 2027:<\/strong> il profilo <em>classic<\/em> di default scende a 64 giorni con un periodo di riuso autorizzazione di 10 giorni<\/li>\n<li><strong>Febbraio 2028:<\/strong> tutti i certificati di default saranno da 45 giorni con riuso autorizzazione di sole 7 ore<\/li>\n<\/ul>\n<p>Il messaggio \u00e8 chiaro: se rinnovi manualmente i certificati, questa pratica diventa insostenibile. L&#8217;automazione non \u00e8 pi\u00f9 un&#8217;opzione, \u00e8 una necessit\u00e0.<\/p>\n<h3>Certificati Short-Lived da 6 Giorni<\/h3>\n<p>Da gennaio 2026, Let&#8217;s Encrypt offre in <em>general availability<\/em> certificati <strong>short-lived<\/strong> validi solo 160 ore (circa 6 giorni). Per richiederli basta selezionare il profilo <em>shortlived<\/em> nel client ACME. Questi certificati non includono URL OCSP o CRL, perch\u00e9 scadono cos\u00ec rapidamente da rendere superflua la revoca tradizionale. Sono perfetti per chi ha un&#8217;automazione solida e vuole la massima sicurezza.<\/p>\n<h3>Fine del Supporto TLS Client Authentication<\/h3>\n<p>Da febbraio 2026, Let&#8217;s Encrypt ha rimosso l&#8217;<em>Extended Key Usage<\/em> &#8220;TLS Client Authentication&#8221; dal profilo di default. Se usi certificati Let&#8217;s Encrypt per <em>mutual TLS<\/em> (mTLS), devi pianificare la migrazione entro maggio 2026, quando anche il profilo temporaneo <em>tlsclient<\/em> verr\u00e0 eliminato.<\/p>\n<h2>Metodo 1: Automazione con Certbot (Il Classico Affidabile)<\/h2>\n<p><strong>Certbot<\/strong> \u00e8 il client ACME ufficiale della EFF ed \u00e8 lo strumento che ho usato per primo sui miei server. La versione attuale \u00e8 la <strong>5.3.1<\/strong> (febbraio 2026) e supporta i nuovi profili ACME, certificati IP e il flag <code>--preferred-profile<\/code>.<\/p>\n<h3>Installazione di Certbot via Snap<\/h3>\n<p>Il metodo consigliato per installare Certbot su qualsiasi distribuzione Linux moderna \u00e8 tramite <em>Snap<\/em>, che garantisce aggiornamenti automatici:<\/p>\n<pre><code># Rimuovi eventuali versioni vecchie installate via apt\nsudo apt remove certbot -y\n\n# Installa Certbot via Snap\nsudo snap install certbot --classic\n\n# Crea il link simbolico\nsudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot\n\n# Verifica la versione installata\ncertbot --version\n<\/code><\/pre>\n<h3>Emissione del Primo Certificato con Certbot<\/h3>\n<p>Nella mia esperienza, il modo pi\u00f9 diretto per ottenere un certificato su un server con <strong>Nginx<\/strong> \u00e8 usare il plugin integrato:<\/p>\n<pre><code># Emetti e configura automaticamente SSL su Nginx\nsudo certbot --nginx -d esempio.it -d www.esempio.it\n\n# Oppure, se usi Apache:\nsudo certbot --apache -d esempio.it -d www.esempio.it\n\n# Solo emissione (certonly), senza modificare la config web server:\nsudo certbot certonly --webroot -w \/var\/www\/esempio.it -d esempio.it -d www.esempio.it\n<\/code><\/pre>\n<h3>Rinnovo Automatico con Certbot<\/h3>\n<p>Certbot installato via Snap crea automaticamente un <em>systemd timer<\/em> (o un cronjob) che tenta il rinnovo due volte al giorno. Puoi verificare che sia attivo:<\/p>\n<pre><code># Verifica il timer di rinnovo automatico\nsudo systemctl status snap.certbot.renew.timer\n\n# Test di rinnovo senza effettivamente rinnovare\nsudo certbot renew --dry-run\n<\/code><\/pre>\n<p>All&#8217;inizio non funzionava perch\u00e9 il timer non era abilitato sulla mia distribuzione. Ho dovuto forzare l&#8217;attivazione:<\/p>\n<pre><code>sudo systemctl enable --now snap.certbot.renew.timer\n<\/code><\/pre>\n<h3>Certbot e Profili ACME 2026<\/h3>\n<p>Con la versione 5.x puoi sfruttare i nuovi <strong>profili ACME<\/strong> di Let&#8217;s Encrypt. Se vuoi testare i certificati da 45 giorni o i <em>short-lived<\/em> da 6 giorni:<\/p>\n<pre><code># Certificato short-lived da 6 giorni\nsudo certbot certonly --nginx -d esempio.it --preferred-profile shortlived\n\n# Certificato con profilo tlsserver (presto a 45 giorni)\nsudo certbot certonly --nginx -d esempio.it --preferred-profile tlsserver\n\n# Certificato per IP address (richiede profilo shortlived)\nsudo certbot certonly --standalone --ip-address 203.0.113.10 --preferred-profile shortlived\n<\/code><\/pre>\n<h2>Metodo 2: Automazione con ACME.sh (Leggero e Potente)<\/h2>\n<p><strong>acme.sh<\/strong> \u00e8 il mio strumento preferito quando lavoro su server minimali o quando ho bisogno di automazione DNS per <em>wildcard certificates<\/em>. \u00c8 uno script shell puro, senza dipendenze, e supporta oltre 150 provider DNS via API.<\/p>\n<h3>Installazione di acme.sh<\/h3>\n<pre><code># Installa acme.sh nella home directory\ncurl https:\/\/get.acme.sh | sh -s email=tuaemail@esempio.it\n\n# Ricarica il terminale per attivare l'alias\nsource ~\/.bashrc\n\n# Verifica l'installazione\nacme.sh --version\n<\/code><\/pre>\n<p>L&#8217;installazione crea automaticamente un <em>cron job giornaliero<\/em> che controlla e rinnova i certificati quando necessario.<\/p>\n<h3>Emissione Certificato con Validazione HTTP (Webroot)<\/h3>\n<pre><code># Certificato singolo con webroot\nacme.sh --issue -d esempio.it -d www.esempio.it -w \/var\/www\/esempio.it\n\n# Con standalone mode (quando non hai un web server in ascolto)\nacme.sh --issue -d esempio.it --standalone\n<\/code><\/pre>\n<h3>Wildcard Certificate con DNS API (Cloudflare)<\/h3>\n<p>Questa \u00e8 la configurazione che uso per i domini gestiti tramite <a href=\"https:\/\/darioiannascoli.it\/blog\/configurare-cloudflare-cdn-sito-web\/\">Cloudflare come CDN<\/a>. Il vantaggio \u00e8 che tutto funziona via API, senza toccare la configurazione del web server:<\/p>\n<pre><code># Esporta le credenziali Cloudflare\nexport CF_Token=\"il_tuo_api_token_cloudflare\"\nexport CF_Email=\"tuaemail@esempio.it\"\n\n# Emetti un wildcard certificate\nacme.sh --issue -d esempio.it -d '*.esempio.it' --dns dns_cf\n<\/code><\/pre>\n<h3>Installazione del Certificato e Reload Automatico<\/h3>\n<p>Dopo l&#8217;emissione, i certificati vanno copiati nella posizione corretta per Nginx o Apache. Questo \u00e8 un passaggio critico che all&#8217;inizio ho sbagliato: <strong>non usare mai direttamente i file dalla cartella ~\/.acme.sh\/<\/strong>, perch\u00e9 la struttura interna pu\u00f2 cambiare. Usa sempre <code>--install-cert<\/code>:<\/p>\n<pre><code># Installazione per Nginx\nacme.sh --install-cert -d esempio.it \n  --key-file \/etc\/ssl\/esempio.it\/key.pem \n  --fullchain-file \/etc\/ssl\/esempio.it\/fullchain.pem \n  --reloadcmd \"systemctl reload nginx\"\n\n# Installazione per Apache\nacme.sh --install-cert -d esempio.it \n  --cert-file \/etc\/ssl\/esempio.it\/cert.pem \n  --key-file \/etc\/ssl\/esempio.it\/key.pem \n  --fullchain-file \/etc\/ssl\/esempio.it\/fullchain.pem \n  --reloadcmd \"systemctl reload apache2\"\n<\/code><\/pre>\n<p>Il parametro <code>--reloadcmd<\/code> \u00e8 fondamentale: senza di esso il certificato viene rinnovato ma il web server continua a servire quello vecchio. Ho perso un&#8217;ora a debuggare questo problema la prima volta.<\/p>\n<h2>Monitoraggio e Notifiche: Non Fidarti Solo dell&#8217;Automazione<\/h2>\n<p>Anche con l&#8217;automazione perfettamente configurata, ho imparato che serve un livello di <strong>monitoraggio<\/strong> indipendente. Let&#8217;s Encrypt ha smesso di inviare email di promemoria per i certificati in scadenza, quindi devi arrangiarti.<\/p>\n<h3>Script di Monitoraggio con OpenSSL<\/h3>\n<p>Ho creato questo semplice script Bash che gira via cronjob e mi avvisa se un certificato scade entro i prossimi 14 giorni:<\/p>\n<pre><code>#!\/bin\/bash\n# check_ssl_expiry.sh - Controlla la scadenza SSL dei domini\n\nDOMAINS=(\"esempio.it\" \"altrosito.it\" \"shop.esempio.it\")\nALERT_DAYS=14\n\nfor DOMAIN in \"${DOMAINS[@]}\"; do\n  EXPIRY=$(echo | openssl s_client -servername \"$DOMAIN\" -connect \"$DOMAIN\":443 2&gt;\/dev\/null \n    | openssl x509 -noout -enddate 2&gt;\/dev\/null | cut -d= -f2)\n  \n  if [ -n \"$EXPIRY\" ]; then\n    EXPIRY_EPOCH=$(date -d \"$EXPIRY\" +%s)\n    NOW_EPOCH=$(date +%s)\n    DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) \/ 86400 ))\n    \n    if [ \"$DAYS_LEFT\" -lt \"$ALERT_DAYS\" ]; then\n      echo \"ATTENZIONE: $DOMAIN scade tra $DAYS_LEFT giorni ($EXPIRY)\" \n        | mail -s \"SSL Alert: $DOMAIN\" admin@esempio.it\n    fi\n  fi\ndone\n<\/code><\/pre>\n<pre><code># Aggiungi al crontab per esecuzione giornaliera\n0 8 * * * \/opt\/scripts\/check_ssl_expiry.sh\n<\/code><\/pre>\n<p>Se utilizzi <a href=\"https:\/\/darioiannascoli.it\/blog\/monitoraggio-risorse-server-plesk-grafana-prometheus\/\">Grafana e Prometheus per il monitoraggio server<\/a>, puoi anche configurare un exporter SSL per avere dashboard e alerting integrati.<\/p>\n<h2>Automazione SSL su Plesk: Cosa Cambia con i Nuovi Certificati<\/h2>\n<p>Chi come me ha gestito server Plesk sa che il pannello integra Let&#8217;s Encrypt nativamente tramite l&#8217;estensione dedicata. Tuttavia, con le novit\u00e0 del 2026, ci sono alcune accortezze importanti. Se stai valutando alternative a Plesk per contenere i costi, ho scritto una guida completa su <a href=\"https:\/\/darioiannascoli.it\/blog\/aumento-prezzi-plesk-2026-alternative-open-source-cloudpanel-1panel-aapanel\/\">come affrontare l&#8217;aumento prezzi Plesk 2026 con alternative open source<\/a>.<\/p>\n<p>Su Plesk, il rinnovo SSL \u00e8 gestito automaticamente dall&#8217;estensione, ma vi consiglio comunque di:<\/p>\n<ul>\n<li>Verificare che l&#8217;estensione Let&#8217;s Encrypt sia aggiornata all&#8217;ultima versione<\/li>\n<li>Controllare i <a href=\"https:\/\/darioiannascoli.it\/blog\/cronjob-plesk-backup-manutenzione-server\/\">cronjob di Plesk<\/a> per assicurarvi che il task di rinnovo sia attivo<\/li>\n<li>Monitorare i log in <code>\/var\/log\/plesk\/<\/code> per errori di rinnovo<\/li>\n<\/ul>\n<h2>Best Practice per il Rinnovo Automatico dei Certificati SSL nel 2026<\/h2>\n<p>Dopo anni di esperienza, ecco le regole d&#8217;oro che seguo:<\/p>\n<ol>\n<li><strong>Non hardcodare gli intervalli di rinnovo:<\/strong> con la riduzione a 45 giorni, un intervallo fisso di 60 giorni non funzioner\u00e0 pi\u00f9. Usa i meccanismi di rinnovo automatico dei client ACME<\/li>\n<li><strong>Abilita ACME Renewal Information (ARI):<\/strong> questo protocollo permette a Let&#8217;s Encrypt di comunicare al tuo client quando \u00e8 il momento ottimale per rinnovare<\/li>\n<li><strong>Testa sempre con &#8211;dry-run:<\/strong> prima di mettere in produzione qualsiasi modifica alla configurazione SSL<\/li>\n<li><strong>Monitora indipendentemente:<\/strong> non fidarti solo del client ACME, usa uno script esterno o un servizio di monitoraggio<\/li>\n<li><strong>Randomizza gli orari di rinnovo:<\/strong> evita di rinnovare a mezzanotte UTC o al primo secondo di ogni ora, perch\u00e9 sovraccarichi i server Let&#8217;s Encrypt<\/li>\n<li><strong>Prepara l&#8217;infrastruttura per certificati pi\u00f9 brevi:<\/strong> se usi reverse proxy, CDN o load balancer, assicurati che la distribuzione e il reload dei certificati siano automatizzati end-to-end<\/li>\n<\/ol>\n<p>Se gestisci configurazioni con <a href=\"https:\/\/darioiannascoli.it\/blog\/reverse-proxy-nginx-piu-siti-server\/\">reverse proxy Nginx per pi\u00f9 siti<\/a>, assicurati che il reload del certificato venga propagato correttamente a tutti i virtual host.<\/p>\n<h2>Certbot vs ACME.sh: Quale Scegliere?<\/h2>\n<p>Nella mia esperienza, la scelta dipende dal contesto:<\/p>\n<ul>\n<li><strong>Certbot<\/strong>: ideale su server Ubuntu\/Debian con Nginx o Apache, installazione via Snap con aggiornamenti automatici, ottimo per chi vuole una soluzione &#8220;set and forget&#8221;<\/li>\n<li><strong>acme.sh<\/strong>: perfetto su server minimali, container, IoT o quando serve integrazione DNS API per wildcard. Zero dipendenze, funziona ovunque ci sia una shell<\/li>\n<\/ul>\n<p>Personalmente uso <strong>Certbot<\/strong> sui server di produzione con Nginx e <strong>acme.sh<\/strong> per i wildcard e le configurazioni pi\u00f9 complesse. Non c&#8217;\u00e8 una risposta giusta per tutti: l&#8217;importante \u00e8 che il rinnovo sia automatico e monitorato.<\/p>\n<h2>FAQ<\/h2>\n<h3>Quando Let&#8217;s Encrypt ridurr\u00e0 la validit\u00e0 dei certificati a 45 giorni?<\/h3>\n<p>La riduzione avverr\u00e0 in fasi: a maggio 2026 il profilo <em>tlsserver<\/em> passer\u00e0 a 45 giorni (opt-in), a febbraio 2027 il profilo di default scender\u00e0 a 64 giorni, e a febbraio 2028 tutti i certificati di default saranno a 45 giorni. Se la tua automazione funziona correttamente, non dovrai fare nulla di speciale.<\/p>\n<h3>Posso usare sia Certbot che acme.sh sullo stesso server?<\/h3>\n<p>Tecnicamente s\u00ec, ma lo sconsiglio fortemente: avere due client ACME attivi sullo stesso server pu\u00f2 causare conflitti, rinnovi duplicati e problemi con i rate limit di Let&#8217;s Encrypt. Scegli uno dei due e usalo per tutti i domini del server.<\/p>\n<h3>Cosa sono i certificati short-lived da 6 giorni di Let&#8217;s Encrypt?<\/h3>\n<p>Sono certificati validi solo 160 ore (circa 6 giorni), disponibili dal gennaio 2026 selezionando il profilo <em>shortlived<\/em> nel client ACME. Non includono informazioni di revoca (OCSP\/CRL) perch\u00e9 scadono troppo rapidamente. Sono consigliati solo se hai un&#8217;automazione di rinnovo completamente affidabile, dato che il client ACME dovrebbe girare almeno una volta al giorno.<\/p>\n<h3>Come verifico quando scade il mio certificato SSL attuale?<\/h3>\n<p>Puoi usare OpenSSL direttamente da terminale: <code>echo | openssl s_client -servername tuodominio.it -connect tuodominio.it:443 2&gt;\/dev\/null | openssl x509 -noout -dates<\/code>. Questo ti mostra le date di emissione e scadenza del certificato attualmente in uso.<\/p>\n<h3>Il rinnovo automatico funziona anche dietro Cloudflare o un reverse proxy?<\/h3>\n<p>S\u00ec, ma con alcune accortezze. Se usi Cloudflare con proxy attivo, la validazione HTTP-01 potrebbe non funzionare: in quel caso usa la validazione DNS-01 con le API di Cloudflare, sia su Certbot (con il plugin <code>certbot-dns-cloudflare<\/code>) che su acme.sh (con <code>--dns dns_cf<\/code>). Nella mia esperienza, la DNS validation \u00e8 sempre la pi\u00f9 affidabile in queste configurazioni.<\/p>\n<h2>Conclusione: Non Restare Mai con un Certificato SSL Scaduto<\/h2>\n<p>Automatizzare il <strong>rinnovo dei certificati SSL\/TLS<\/strong> nel 2026 non \u00e8 pi\u00f9 un lusso da sysadmin esperti: con Let&#8217;s Encrypt che riduce la validit\u00e0 a 45 giorni e introduce certificati da 6 giorni, \u00e8 una competenza fondamentale per chiunque gestisca un server. Che tu scelga <strong>Certbot<\/strong> per la sua semplicit\u00e0 o <strong>acme.sh<\/strong> per la sua flessibilit\u00e0, l&#8217;importante \u00e8 che il rinnovo sia completamente automatico, il reload del web server sia integrato nel processo, e un sistema di monitoraggio indipendente ti avvisi in caso di problemi.<\/p>\n<p>Nella mia esperienza, investire un&#8217;ora per configurare correttamente l&#8217;automazione SSL ti risparmia decine di ore di troubleshooting e \u2014 soprattutto \u2014 ti evita quella telefonata alle 3 di notte perch\u00e9 il sito del cliente \u00e8 down per un certificato scaduto.<\/p>\n<p>Hai domande sulla configurazione dei tuoi certificati SSL? Lascia un commento qui sotto e ti aiuto volentieri!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Guida pratica per automatizzare il rinnovo certificati SSL\/TLS con Certbot, acme.sh e Let&#8217;s Encrypt nel 2026: comandi, monitoraggio e best practice.<\/p>\n","protected":false},"author":1,"featured_media":1452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Rinnovo Automatico Certificati SSL con Certbot e ACME.sh","_seopress_titles_desc":"Come automatizzare il rinnovo certificati SSL\/TLS con Certbot, acme.sh e Let's Encrypt nel 2026: guida step-by-step con comandi testati e monitoraggio.","_seopress_robots_index":"","footnotes":""},"categories":[3],"tags":[368,366,367,120,118,365],"class_list":["post-1451","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-acme-sh","tag-certbot","tag-lets-encrypt","tag-linux","tag-sicurezza-server","tag-ssl-tls"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1451","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=1451"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1451\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1452"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1451"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1451"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1451"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}