Il vostro certificato è scaduto o sta per scadere? In questa guida vi mostrerò nello specifico come Rinnovo del certificato SSL manualmente e automaticamente, comprese le insidie tipiche, gli strumenti e le impostazioni adatte.
Vi guiderò attraverso l'hosting, i server personalizzati e WordPress per aiutarvi a evitare interruzioni, aumentare la sicurezza e proteggere le conversioni - da CSR a HSTS, da Let's Encrypt a Wildcard.
Punti centrali
- Automatico Estendere: Attivare l'opzione hoster, verificare lo stato
- Manuale Rinnovo: creare CSR, installare, testare la catena
- WordPress sicuro: Applicare l'HTTPS, utilizzare i plugin
- Errore evitare: .well-known, catena, reindirizzamenti
- Precauzione incontrare: Monitoraggio, Cronjobs, HSTS
Perché i certificati SSL scadono e cosa significa per voi
Ogni certificato ha una durata prestabilita, per i certificati pubblici un massimo di 397 giorni. Dopo la scadenza, il browser blocca la connessione, i visitatori vedono avvisi e spesso rinunciano. Questo danneggia la fiducia, la conversione e la visibilità nei motori di ricerca. Evito questo rischio tenendo d'occhio per tempo la data di scadenza e pianificando il rinnovo. Chi rinnova per tempo rimane conforme alla legge e protegge le trasmissioni di dati.
Attivare il rinnovo automatico con il provider di hosting
Molti pannelli di hosting offrono l'attivazione con un solo clic per Rinnovo automatico. Attivo l'opzione per dominio, controllo la convalida memorizzata (HTTP-01/DNS-01) e poi verifico la validità nel blocco del browser. Con diversi domini e sottodomini, risparmio molto tempo ed evito le lacune tra due certificati. Per un avvio di base sicuro, il compatto 5 passi per un sito web sicuro. Dopodiché, mi limito a tenere d'occhio gli avvisi di scadenza dell'hoster e a testare regolarmente l'accessibilità HTTPS.
Mi assicuro inoltre che il Contatto e-mail è aggiornato nell'account dell'hoster in modo da ricevere i messaggi di scadenza e di errore. Se il rinnovo automatico viene eseguito tramite ACME, tengo conto di Limiti tariffari della CA e, se disponibile, utilizzo un ambiente di staging per i test, in modo da non bloccarmi inavvertitamente. Per la convalida DNS-01, pianifico i TTL in modo che le voci si propaghino rapidamente. C'è Record CAA nella zona, verifico se la mia autorità di certificazione è consentita in quella zona, altrimenti il rinnovo fallirà nonostante il rinnovo automatico.
Per le configurazioni multidominio o wildcard, verifico se l'hoster supporta l'opzione Aggiornamento automatico del DNS supportato. Senza una connessione API, definisco processi chiari: Chi crea i record TXT, chi controlla la risoluzione e quando vengono rimossi? Questo lavoro preparatorio assicura che il rinnovo automatico non fallisca a causa di ostacoli organizzativi.
Estensione manuale: dal CSR all'installazione
Per requisiti speciali, server root o determinate autorità di certificazione, rinnovo manualmente. Per prima cosa, creo un nuovo CSR con una chiave adeguata (RSA 2048+ o ECDSA), includendo il nome comune corretto e i nomi alternativi del soggetto. Avvio l'ordine di rinnovo nel portale della CA, confermo il controllo del dominio (ad esempio HTTP-01 tramite .well-known o DNS-01 tramite TXT) e attendo l'emissione. Quindi scarico il certificato e i certificati intermedi e controllo la catena in locale. Memorizzo il certificato, la chiave e l'intermedio nel pannello di hosting (ad es. Plesk o cPanel) e verifico la catena. Catena con un controllo SSL.
Di solito uso Nuove chiavi ad ogni rinnovo, per mantenere aggiornati gli standard crittografici. Per ECDSA, ad esempio, utilizzo una curva come prime256v1; per RSA scelgo almeno 2048 bit. Il CSR contiene sempre tutti i nomi di host che desidero proteggere, tra cui Dominio di base e www (ad esempio example.tld e www.example.tld). Pianifico l'installazione in modo che il nuovo certificato sia pronto prima della scadenza di quello vecchio; molti server lo consentono. Sostituzione senza problemi con un ricarico senza tempi di inattività.
Dopo l'installazione, ho testato la consegna sia con www che senza www, attraverso IPv4 e IPv6e controllo la catena completa. Se la catena non è corretta, importo l'intermedio appropriato della CA. Mi assicuro che il server sia solo ricaricare (ricarica della configurazione), non riavviare l'hard per evitare che le connessioni attive vengano annullate.
Pratica del server: Apache, Nginx e IIS in sintesi
Con Apache Memorizzo i percorsi nel vHost: SSLCertificateFile (certificato del server), SSLCertificateKeyFile (chiave privata) e, a seconda della versione, SSLCertificateChainFile o un file full-chain in bundle. Dopo lo scambio, controllo la configurazione e la ricarico. Per Nginx Ho impostato ssl_certificate (catena completa) e ssl_certificate_key (chiave). Collaudo la configurazione, la ricarico e poi verifico la gestione di HTTP/2/HTTP/3 e SNI tramite diversi nomi di server.
All'indirizzo IIS Importo il certificato nell'archivio dei certificati (computer) e lo lego al sito. È importante che per ogni hostname SNI se diversi certificati sono in esecuzione sullo stesso IP. Per le configurazioni automatiche di Windows, programmo un client ACME per gestire il rinnovo e il binding. In tutti i casi, documento i percorsi, i permessi dei file (chiave solo per il processo del server web) e la procedura esatta in modo che la prossima data di rinnovo si svolga senza problemi.
SSL in WordPress: configurare, applicare, estendere automaticamente
Con WordPress lo tengo sempliceAttivo Let's Encrypt nell'hosting, impongo l'HTTPS tramite plugin (ad esempio Really Simple SSL) e controllo i widget di contenuto misto. Se WordPress gira su un proprio server, utilizzo Certbot con un cronjob per il rinnovo automatico. Nelle configurazioni multisito, un certificato wildcard è utile per proteggere collettivamente i sottodomini. Utilizzo questo tutorial per un avvio rapido: SSL gratuito in WordPress. Controllo quindi il simbolo del lucchetto nel browser e la data di scadenza del certificato negli strumenti di WordPress.
Dopo la sostituzione sostituisco collegamenti hard http nel database, in modo che immagini, script e stili vengano caricati in modo pulito tramite HTTPS. Controllo anche i plugin di caching e le integrazioni CDN per assicurarmi che gestiscano correttamente la variante HTTPS. Importante: quando si forza l'HTTPS, faccio attenzione ai reindirizzamenti puliti (una catena 301), in modo da non diluire i segnali SEO e non creare loop infiniti.
Sui miei server ho intenzione di utilizzare Certbot-Renewal come Cronjob e memorizzare ganci per i post che ricaricano Nginx/Apache dopo l'avvenuto rinnovo. Negli ambienti WordPress gestiti, utilizzo le funzioni di rinnovo automatico dell'hoster e verifico regolarmente se le sfide .well-known sono accessibili, soprattutto quando i plugin di sicurezza o le regole WAF sono rigorosamente applicate.
Evitare gli errori tipici: Convalida, catena, reindirizzamento
Spesso il Convalidase il file HTTP-01 sotto /.well-known/pki-validation/ non è accessibile. Per il rinnovo, disattivo brevemente i reindirizzamenti aggressivi (ad esempio da non-www a www) o le regole che bloccano l'accesso. Se mancano i certificati intermedi, i browser rifiutano il certificato; importo la catena completa. Se ci sono più certificati su un IP, l'SNI deve essere attivo, altrimenti il server consegnerà il certificato sbagliato. Cancello le cache dopo ogni modifica, in modo da poter vedere lo stato reale e attuale.
Altri pericoli tipici di inciampo: A Record AAAA (IPv6) punta a un server diverso da A (IPv4), la sfida fallisce. Oppure il WAF blocca l'accesso a .well-known. Con DNS-01, i TTL elevati causano ritardi; li ho temporaneamente impostati più bassi. Esistere Record CAA senza l'approvazione della CA utilizzata, annullo il rinnovo finché la voce non viene corretta. Negli ambienti container o chroot, faccio attenzione ai mount e ai permessi corretti, in modo che il server web o il client ACME possano effettivamente consegnare i file di sfida.
Confronto tra hosting: chi rinnova in modo più affidabile?
Presto attenzione a un Intuitivo interfaccia, il rinnovo automatico per tutti i domini e un'assistenza rapida. Questo mi fa risparmiare tempo di manutenzione e riduce significativamente i tempi di inattività. Per i provider con l'integrazione di Let's Encrypt, imposto l'opzione di rinnovo automatico una volta e controllo l'accessibilità tramite il monitoraggio HTTPS. Ci sono istruzioni chiare per All-Inkl che rendono l'attivazione molto rapida: Let's Encrypt a All-Inkl. La tabella seguente mostra gli elementi che ritengo particolarmente importanti nel confronto.
| Provider di hosting | Rinnovo automatico | Superficie | Supporto | Valutazione |
|---|---|---|---|---|
| webhoster.de | Sì | Molto intuitivo | Veloce | 1° posto |
| Tutti i prodotti | Sì | Semplice | Buono | 2° posto |
| Ospitare l'Europa | Parzialmente | Medio | Medio | 3° posto |
| Web hosting SSD | Parzialmente | Medio | Medio | 4° posto |
Verifico anche se il fornitore API DNS per DNS-01 (importante per i caratteri jolly), fornisce informazioni sui log per le convalide fallite e se i certificati possono essere esportati comodamente come catena completa. Un buon pannello mostra Certificati in scadenza Il sistema inizia in una fase iniziale, consente diritti granulari (ad esempio, solo la gestione della SSL) e documenta ogni fase. In questo modo si risparmia tempo e si evita che la conoscenza sia legata a singole persone.
Riconoscere i processi e prevenirli in modo proattivo
Posso vedere lo stato in qualsiasi momento tramite il menu Castello-Nel browser, i dettagli del certificato forniscono informazioni sulla validità e sull'emittente. Ho anche impostato le notifiche nel pannello di hosting e il monitoraggio che avverte della scadenza. I miei server hanno un cron job che esegue regolarmente Certbot e controlla i log. In WordPress, controllo le notifiche dei plugin di sicurezza e monitoro la console per i contenuti misti. Questa combinazione evita i tempi di inattività e mantiene la crittografia attiva senza interruzioni.
Per il Controllo tecnico Utilizzo controlli semplici: Recupero delle date di scadenza dei certificati, verifica della catena e del supporto del protocollo (TLS 1.2/1.3). Nel monitoraggio, pianifico i livelli di avviso (ad esempio 30, 14 e 7 giorni prima della scadenza) e verifico se i ganci di ricarica sono stati effettivamente attivati dopo un rinnovo riuscito. Questo mi permette di riconoscere i problemi in una fase iniziale, prima che i visitatori vedano le pagine di avviso.
Messa a punto della sicurezza dopo il rinnovo
Dopo il rinnovo, ottengo il massimo da TLS e attivo TLS 1.3 (oltre alla 1.2), disattivare i vecchi protocolli e i cifrari obsoleti. HSTS con un tempo massimo sufficientemente lungo vincola i client a HTTPS e riduce le superfici di attacco. La pinzatura OCSP riduce le latenze e solleva il risponditore OCSP dalla CA. Se si utilizza RSA, scegliere 2048 bit o passare a ECDSA per ottenere prestazioni migliori, se necessario. Alla fine, convalido la configurazione con un test SSL e analizzo da vicino i protocolli e le impostazioni crittografiche.
Preferisco cifrario moderno con Forward Secrecy e attivo ALPN in modo che HTTP/2 e HTTP/3 siano utilizzati in modo efficiente. Se disponibile, imposto il protocollo parallelo Certificati ECDSA e RSA In questo modo, i client moderni ottengono la variante ECDSA ad alte prestazioni, mentre i client più vecchi rimangono compatibili con RSA. Aumento l'HSTS gradualmente (ad esempio, prima giorni, poi settimane) per evitare di consolidare in modo permanente le configurazioni errate. Controllo attivamente lo stapling OCSP dopo la ricarica, in modo che i client non abbiano ulteriori latenze di rete.
Procedura pratica in breve
Comincio con un controllo dello stato, prendo nota del Data di scadenza e decidere: lasciare attivo il rinnovo automatico o rinnovare manualmente. Per il rinnovo automatico, controllo il percorso di convalida (HTTP-01/DNS-01) e verifico l'accessibilità della sfida. Per il rinnovo manuale, creo il CSR, richiedo il certificato all'autorità di certificazione e installo il certificato e la catena. Quindi impongo l'HTTPS, elimino le cache e controllo i contenuti misti. Infine, imposto il monitoraggio e le notifiche in modo da non perdere mai più una scadenza.
Casi speciali: Wildcard, multidominio e tipi di convalida
Se gestisco molti sottodomini, utilizzo un file Jolly-certificate (*.domain.tld) e mi risparmio certificati separati. Per molti domini completamente diversi, mi affido a certificati SAN/UCC che riassumono diversi nomi di host. I certificati DV sono sufficienti per la maggior parte dei progetti, mentre OV/EV forniscono un'ulteriore verifica dell'identità, utile per negozi o portali con dati sensibili. Faccio attenzione ai limiti di tempo di esecuzione e pianifico il rinnovo in modo che non ci siano interruzioni durante i picchi di funzionamento. Per la convalida del DNS sulle zone produttive, lavoro con convenzioni di denominazione chiare, in modo da poter ritrovare rapidamente le voci e Cambiamento può.
All'indirizzo Jolly è importante: la convalida viene eseguita esclusivamente tramite DNS-01, quindi utilizzo aggiornamenti DNS automatici o finestre di manutenzione dedicate. Negli ambienti multidominio, mi assicuro che tutte le varianti siano presenti nell'elenco SAN (compresi i sottodomini aggiunti nel corso dell'anno). Per le configurazioni del bilanciatore di carico, pianifico il Distribuzione dei nuovi certificati a tutti i nodi e poi testare ogni VIP/regione separatamente. Quando i team cambiano, è utile avere una documentazione chiara su chi riceve quali segreti (chiavi) e quando, e su come vengono conservati in modo sicuro.
ACME e ambienti complessi: CDN, WAF e reverse proxy
Utilizzo CDN o un WAF, mi assicuro che la convalida raggiunga l'origine: o faccio rispondere le richieste di sfida all'Edge (se supportato) o eseguo bypass mirati per /.well-known/ on. Per HTTP-01, può esserci un reindirizzamento a HTTPS, ma la sfida deve essere accessibile senza intestazioni auth, limiti di velocità o geoblocchi. Per DNS-01, verifico se la voce TXT è disponibile in tutto il mondo e se nessuna configurazione di split horizon interferisce con la valutazione.
Dietro Proxy inverso Controllo le intestazioni più indietro (X-Forwarded-Proto) in modo che l'applicazione reagisca correttamente all'HTTPS e non generi errori di contenuto misto. Per i rinnovi a tempo zero, faccio rotolare i certificati passo dopo passo prima un nodo, poi gli altri, in modo da poter tornare indietro rapidamente in caso di problemi senza rischiare tutte le connessioni.
Piano di emergenza: cancellazione, perdita della chiave e sostituzione rapida
Se c'è un Perdita di chiave o una compromissione, revoco immediatamente il certificato e ne emetto uno nuovo con nuove chiavi. Conservo un Lista di controllo pronto: Accesso al portale della CA, procedura di revoca, generazione di nuove chiavi, distribuzione rapida e ricarica. Controllo poi la pinzatura OCSP e le cache per rimuovere le vecchie catene dalle cache. Annoto la causa, il momento e le contromisure nella documentazione: questo facilita gli audit e previene le recidive.
Riassumendo brevemente
Rinnovo tempestivamente i certificati, controllo il Rinnovo automatico-e mantenere la convalida accessibile. Nei casi in cui il rinnovo automatico non funziona, lo faccio manualmente: genero il CSR, lo applico, installo la catena, verifico l'HTTPS. Proteggo WordPress con HTTPS forzato e monitoraggio, i miei server sono controllati da cronjob e Certbot. Evito gli errori tenendo d'occhio la sfida .well-known, i certificati intermedi, l'SNI e le regole di inoltro. Con questo processo, la crittografia rimane attiva, gli utenti si fidano del sito e la visibilità non soffre di avvisi di scadenza.
