Come configurare SSL e HTTPS su PrestaShop

Ultimo aggiornamento: giugno 2026.

Ecco la parte di una migrazione SSL che coglie di sorpresa i proprietari di negozi PrestaShop: acquistare il certificato è il 10% facile. Il certificato si installa sul server in pochi minuti. L'altro 90%, la parte che rompe davvero i negozi, avviene dentro PrestaShop, dove SSL è collegato al database, al riscrittore degli URL, all'ambito dei cookie e a un interruttore Attiva SSL su tutte le pagine da gestire a step, che può tagliarti fuori dal tuo pannello di amministrazione se lo attivi nell'ordine sbagliato. Questa guida parla di quel 90%: configurare HTTPS correttamente su PrestaShop nello specifico, con i percorsi reali del pannello di amministrazione, le chiavi di configurazione esatte e la procedura di recupero quando qualcosa va storto.

Se vuoi una panoramica più ampia su come mettere in sicurezza un negozio, sicurezza dell'amministrazione, regole server, patching virtuale, questo è solo un punto di una lista più lunga; inizia dalla checklist di hardening della sicurezza PrestaShop. Questo articolo resta concentrato su SSL e HTTPS.

Perché è indispensabile per un negozio PrestaShop

Probabilmente sai già che HTTPS cifra la connessione. In termini commerciali, i motivi per cui è obbligatorio per un negozio sono questi:

• I browser spaventano attivamente i tuoi clienti quando usi HTTP. Chrome e Firefox etichettano le pagine in semplice HTTP come "Non sicuro" nella barra degli indirizzi, proprio nelle pagine in cui il cliente sta per inserire il numero della carta. È un problema di conversione, non solo di sicurezza.
• Le integrazioni di pagamento lo richiedono. I webhook e i flussi di reindirizzamento di Stripe, PayPal, Mollie e Adyen presuppongono URL HTTPS. Un certificato configurato a metà è una delle cause silenziose per cui una notifica di ritorno del pagamento fallisce senza messaggi evidenti.
• È un segnale di posizionamento e una porta d'accesso a HTTP/2. Google considera HTTPS un fattore di posizionamento leggero dal 2014, e HTTP/2, che accelera davvero il caricamento delle pagine grazie al multiplexing, è disponibile solo su HTTPS. Quindi la scelta che ti rende più sicuro ti rende anche più veloce.

Il punto pratico: farlo bene elimina un avviso del browser dalla procedura di pagamento, mantiene attive le notifiche di ritorno dei pagamenti e sblocca un livello di prestazioni gratuito. Farlo a metà, certificato presente ma PrestaShop configurato male, produce avvisi di contenuto misto e layout rotti che appaiono peggiori di quanto sarebbe mai apparso un semplice HTTP.

Quale certificato comprare davvero (spoiler: probabilmente nessuno)

I certificati SSL esistono in tre livelli di validazione. La cifratura è identica in tutti e tre, la differenza di prezzo paga la documentazione di validazione, non una sicurezza più forte.

Un certificato DV gratuito di Let's Encrypt dà al browser del cliente lo stesso identico lucchetto e la stessa identica cifratura di un certificato EV da 500 EUR. A meno che tu non gestisca un'attività B2B regolamentata, i cui acquirenti controllano specificamente i dettagli del certificato, scegli il DV gratuito e investi quei soldi nel tuo negozio.

Passaggio 1: installa il certificato sul server

Questo avviene a livello di hosting, prima che PrestaShop entri in gioco. Scegli il percorso adatto alla tua configurazione.

• cPanel: apri SSL/TLS Status e fai clic su Run AutoSSL. Emette e installa certificati Let's Encrypt per ogni dominio e li rinnova automaticamente con un ciclo di 60–90 giorni.
• Plesk: Websites & Domains → SSL/TLS Certificates → Install sotto Let's Encrypt, e seleziona il rinnovo automatico.
• VPS / dedicato (accesso root): installa Certbot. certbot --apache o certbot --nginx ottiene il certificato, modifica il vhost e aggiunge un cron/timer di rinnovo. È il percorso più pulito se controlli il server.
• Cloudflare: il piano gratuito termina SSL sull'edge di Cloudflare. Dettaglio critico qui sotto, impostalo su Full (Strict), mai su Flexible.

Vale la pena evidenziare una trappola di Cloudflare, perché colpisce in modo specifico i negozi PrestaShop: in modalità Flexible il tratto visitatore-Cloudflare è cifrato, ma il tratto Cloudflare-server è in semplice HTTP. Il lucchetto sembra a posto, ma PrestaShop vede una richiesta HTTP, e questa incongruenza è la causa numero uno del loop di reindirizzamento nella sezione di risoluzione dei problemi qui sotto. Usa Full (Strict), che richiede un certificato sull'origine (anche un Let's Encrypt gratuito) e cifra entrambi i tratti.

Passaggio 2: attiva SSL dentro PrestaShop, nell'ordine giusto

Con il certificato attivo sul server, PrestaShop deve comunque sapere che deve usarlo. Questo è il passaggio che blocca molte persone fuori dal pannello di amministrazione, quindi procedi con calma.

Vai a Parametri negozio → Generale nel pannello di amministrazione (PrestaShop 1.7, 8 e 9.x). Ci sono due interruttori, e l'ordine conta:

• Imposta Attiva SSL su Sì e salva. In questo modo PrestaShop serve le pagine sensibili (accesso, procedura di pagamento, account) su HTTPS, lasciando il resto invariato. Verifica che il pannello di amministrazione e una procedura di pagamento continuino a caricarsi.
• Solo dopo imposta Attiva SSL su tutte le pagine su Sì. Questo forza ogni URL del negozio pubblico su HTTPS.

Perché questa procedura in due passaggi: se il certificato o la configurazione del proxy hanno un problema sottile e attivi entrambe le opzioni insieme, PrestaShop può iniziare a reindirizzare l'amministrazione verso un indirizzo HTTPS non funzionante e perdi l'accesso proprio alla schermata che ti serve per annullare la modifica. Attivarle una alla volta fa emergere il problema mentre puoi ancora raggiungere il pannello di amministrazione.

Se ti sei comunque chiuso fuori

Questa è la procedura di recupero da ricordare. I due interruttori corrispondono a due righe in ps_configuration: PS_SSL_ENABLED e PS_SSL_ENABLED_EVERYWHERE. Apri phpMyAdmin (o il client DB che preferisci) e imposta entrambi a 0:

UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

(Sostituisci ps_ con il prefisso reale delle tue tabelle.) Questo disattiva l'obbligo di SSL, ripristina l'accesso all'amministrazione e ti consente di correggere il vero problema, di solito la questione dell'header del proxy spiegata più avanti, prima di riprovare. Svuota poi la cache (elimina il contenuto di var/cache/) in modo che la modifica abbia effetto.

Imposta correttamente gli URL del negozio

Vai a Parametri negozio → Traffico & SEO → SEO & URL e usa il pannello Imposta URL negozio in fondo alla pagina (in multinegozio c'è la schermata dedicata URL negozio). I campi Dominio negozio e Dominio SSL devono essere identici, nomi host semplici come yourstore.com, senza prefisso http:// o https:// e senza barra finale. PrestaShop aggiunge il protocollo da solo in base agli interruttori SSL. Incollare un URL completo in questi campi è una causa classica di indirizzi duplicati come https://https//yourstore.com.

Passaggio 3: reindirizza tutto il traffico HTTP verso HTTPS

Dopo aver attivato SSL dentro PrestaShop, forza il reindirizzamento prima che l'applicazione faccia qualunque lavoro. Inserisci la regola vicino all'inizio del file pubblico .htaccess, dopo averla testata su staging.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Attivare SSL "su tutte le pagine" fa generare a PrestaShop link HTTPS, ma vecchi segnalibri, backlink e indirizzi digitati arrivano ancora via HTTP. Un unico indirizzo HTTPS canonico, applicato con un reindirizzamento 301, mantiene i clienti sulla versione cifrata e impedisce ai motori di ricerca di trattare HTTP e HTTPS come siti duplicati.

La trappola specifica di PrestaShop: PrestaShop controlla il suo .htaccess. Nel momento in cui qualcuno fa clic su Genera file .htaccess in Parametri negozio → Traffico & SEO → SEO & URL, l'intero file viene riscritto e ogni regola di reindirizzamento aggiunta a mano sparisce. Il reindirizzamento stesso, e il modo sicuro per aggiungere regole che sopravvivono alla rigenerazione, appartengono alla configurazione a livello di file, trattata in dettaglio in PrestaShop .htaccess: regole di sicurezza e prestazioni. Le opzioni più pulite, che evitano del tutto il problema della rigenerazione:

• Cloudflare: attiva Always Use HTTPS in SSL/TLS → Edge Certificates. Il reindirizzamento avviene sull'edge prima che la richiesta raggiunga il server, più veloce e immune alla rigenerazione di .htaccess.
• Nginx: un blocco server sulla porta 80 che esegue return 301 https://$host$request_uri;, una configurazione che PrestaShop non tocca mai.

Passaggio 4: scova il contenuto misto (la parte che rompe i layout)

Il contenuto misto è il problema su cui passerai davvero tempo. Una pagina HTTPS che carica un'immagine, uno script o un foglio di stile tramite http:// genera avvisi del browser, e i browser moderni bloccano del tutto gli script misti, motivo per cui un negozio può apparire completamente senza stile o avere un modulo di pagamento non funzionante subito dopo la migrazione.

Per trovarlo: apri il negozio in Chrome, premi F12 e leggi la scheda Console per righe come "Mixed Content: the page at https://… requested an insecure resource http://…". Ognuna indica l'URL responsabile.

Su PrestaShop, il contenuto misto si concentra in alcuni punti prevedibili:

• http:// codificato in modo fisso nel database. Descrizioni prodotto, descrizioni categoria e pagine CMS in cui qualcuno ha incollato un URL immagine assoluto con http://. È la fonte più comune.
• Risorse dei moduli. Moduli vecchi o scritti male che registrano CSS/JS con un URL esplicito http:// invece di usare $this->context->link / helper consapevoli del protocollo di PrestaShop. Aggiorna il modulo o segnala il problema al suo sviluppatore.
• Modelli email. Immagini richiamate via HTTP nelle email transazionali, modificate da Design → Tema email.
• File del tema. URL di CSS background-image o font fissati su http:// nei fogli di stile di un tema personalizzato.
• Incorporamenti di terze parti. Font, analytics, video o widget social caricati via HTTP.

Il cerca-e-sostituisci nel database

Per le occorrenze nel database, esegui aggiornamenti mirati dopo aver fatto un backup. I campi più importanti sono in ps_product_lang (description, description_short), ps_category_lang (description) e ps_cms_lang (content):

UPDATE ps_product_lang SET description = REPLACE(description, 'http://yourstore.com', 'https://yourstore.com');

Ripeti per ogni campo e tabella. La correzione robusta a lungo termine è usare URL HTTPS o relativi al protocollo nei contenuti futuri; ancora meglio, smettere del tutto di incollare URL assoluti con dominio nelle descrizioni. Fai sempre un backup del database prima di qualunque UPDATE massivo, non c'è annulla.

Passaggio 5: aggiorna i servizi esterni che ti considerano ancora in HTTP

Google tratta http:// e https:// come proprietà separate, quindi una migrazione che salta questo passaggio ti fa uscire silenziosamente dai tuoi stessi report. Procedi così:

• Google Search Console: aggiungi https://yourstore.com come nuova proprietà, non eredita la cronologia da quella HTTP.
• Google Analytics / Merchant Center: aggiorna l'URL della proprietà/del sito a https://; un vecchio URL HTTP del flusso prodotti in Merchant Center può far disapprovare i prodotti.
• Sitemap: rigenerala in modo che ogni voce sia in HTTPS. Se usi un modulo sitemap, rigenerala tramite il modulo invece che con lo strumento principale. Il nostro modulo sitemap di mypresta.rocks rileva automaticamente il protocollo dalle impostazioni SSL, quindi una rigenerazione dopo l'attivazione di SSL produce URL HTTPS puliti senza modifiche manuali, una cosa in meno da ricordare.
• Webhook di pagamento: aggiorna gli URL di notifica nei pannelli dei fornitori, PayPal IPN, URL webhook di Stripe, webhook Mollie, a https://. Un webhook rimasto in HTTP è un errore silenzioso nello stato dell'ordine.

Passaggio 6: verifica, non dare per scontato

Esegui questa checklist prima di considerare il lavoro concluso:

• La homepage su HTTPS mostra un lucchetto pulito, senza avvisi.
• Pagine prodotto, categoria e CMS, Console priva di contenuto misto.
• Una procedura completa di acquisto di test si conclude su HTTPS, notifica di ritorno del pagamento inclusa.
• Ogni pagina del pannello di amministrazione si carica su HTTPS.
• Digitare http://yourstore.com reindirizza con 301 a https://.
• Un solo host canonico, www o non-www, non entrambi risolti.
• Esegui il test gratuito SSL Labs server test (ssllabs.com/ssltest); punta a un voto A o A+.

I tre problemi che spiegano la maggior parte dei ticket "HTTPS ha rotto il mio negozio"

Loop di reindirizzamento infinito

Il caso classico. Il tuo hosting o Cloudflare termina SSL a monte e inoltra la richiesta a PrestaShop come semplice HTTP. PrestaShop vede HTTP, reindirizza a HTTPS, il proxy gliela rimanda come HTTP, all'infinito. La soluzione è fare in modo che PrestaShop si fidi dell'header X-Forwarded-Proto del proxy, così riconosce che la richiesta originale era HTTPS. Su Cloudflare in particolare, passare da Flexible a Full (Strict) risolve direttamente il problema. Su altri reverse proxy potresti dover rispettare l'header forwarded-proto a livello di web server o di .htaccess.

Negozio senza stile / modulo di pagamento bloccato

Quasi sempre contenuto misto bloccato, un foglio di stile o uno script che il browser ha rifiutato di caricare via HTTP su una pagina HTTPS. Torna al Passaggio 4: leggi la Console, trova la risorsa http://, correggi la sorgente.

Immagini scomparse dopo la migrazione

Immagini prodotto o CMS con URL http:// codificati in modo fisso, oppure una CDN immagini che non serve HTTPS. Il cerca-e-sostituisci nel database del Passaggio 4 gestisce il primo caso; per il secondo, conferma che la tua CDN/il tuo host immagini supporti HTTPS.

Una nota su come andare oltre

Una volta che HTTPS è pulito e verificato, il passo naturale successivo è HSTS (HTTP Strict Transport Security), che dice ai browser di rifiutare completamente HTTP per il tuo dominio. È potente e leggermente pericoloso, un max-age troppo lungo su un sito configurato male può rendere il dominio irraggiungibile, quindi appartiene al resto dell'hardening degli header di sicurezza, non a una nota inserita di corsa qui. Trattiamo HSTS, gli header di sicurezza e le altre regole a livello server nella guida sicurezza e prestazioni .htaccess, e SSL rientra nel programma più ampio nella checklist completa di hardening. Se preferisci prima una spiegazione senza gergo tecnico, la guida in parole semplici per mettere in sicurezza il tuo negozio è un punto di partenza più graduale.

SSL su PrestaShop non è difficile, ma non perdona né l'ordine delle operazioni né le particolarità della piattaforma: attiva gli interruttori uno alla volta, conosci il recupero tramite ps_configuration prima di averne bisogno, aspettati che il database nasconda gli ultimi URL http:// e verifica con la Console invece che a occhio. Fai così e il risultato è immediato, niente "Non sicuro" sulla procedura di pagamento, notifiche di ritorno dei pagamenti che partono e velocità HTTP/2 gratuita. Fallo diventare il progetto di questa settimana; è uno dei pomeriggi a più alto valore che puoi dedicare al negozio.

Domande frequenti

Ho attivato SSL e ora il pannello di amministrazione reindirizza all'infinito, come rientro?

Questo è il loop di reindirizzamento, e quasi sempre dipende da un proxy che serve a PrestaShop una richiesta in semplice HTTP mentre il tratto browser-edge è HTTPS. Il recupero rapido consiste nel disattivare l'obbligo nel database: UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE'); (sostituisci il prefisso delle tabelle), poi svuota la cache eliminando il contenuto di var/cache/. Questo ripristina l'accesso all'amministrazione. Prima di riattivare SSL, correggi la causa reale, su Cloudflare passa da Flexible a Full (Strict); su un altro reverse proxy, fai in modo che PrestaShop rispetti l'header X-Forwarded-Proto, così riconosce che la richiesta originale era HTTPS.

Un certificato gratuito Let's Encrypt è davvero sicuro quanto uno a pagamento?

Per la cifratura, sì, è identico. Un certificato DV di Let's Encrypt dà al browser del visitatore lo stesso lucchetto e la stessa cifratura TLS di un certificato EV da 500 EUR. Il prezzo di OV ed EV paga la documentazione di validazione (viene controllata l'identità legale della tua azienda), non una crittografia più forte, e i browser hanno rimosso la barra verde con il nome dell'azienda, che era l'unico beneficio visibile degli EV. A meno che tu non gestisca un'attività B2B regolamentata, i cui acquirenti controllano specificamente i dettagli del certificato, scegli il DV gratuito.

Il mio negozio si carica senza stile o il modulo di pagamento è bloccato dopo il passaggio a HTTPS, perché?

Quasi sempre per contenuto misto bloccato: una pagina HTTPS sta caricando un foglio di stile o uno script tramite http://, e i browser moderni rifiutano di caricare script non sicuri su una pagina sicura. Apri il negozio in Chrome, premi F12 e leggi la scheda Console, ogni riga "Mixed Content" indica l'URL http:// responsabile. I colpevoli abituali sono link assoluti http:// incollati nei contenuti prodotto o CMS (da correggere con un cerca-e-sostituisci nel database dopo il backup), moduli vecchi che registrano risorse con un protocollo codificato in modo fisso e fogli di stile di temi personalizzati. Correggi la sorgente, non il sintomo.

Perché devo attivare i due interruttori SSL uno alla volta?

Perché l'ordine è la tua rete di sicurezza. Attiva SSL (PS_SSL_ENABLED) forza HTTPS solo sulle pagine sensibili, accesso, procedura di pagamento, account, quindi se il certificato o il proxy hanno un problema sottile, il problema emerge mentre puoi ancora raggiungere il pannello di amministrazione. Solo dopo aver verificato che l'amministrazione e una procedura di pagamento si carichino ancora imposti Attiva SSL su tutte le pagine (PS_SSL_ENABLED_EVERYWHERE). Attiva entrambe insieme su una configurazione rotta e PrestaShop può iniziare a reindirizzare l'amministrazione verso un URL HTTPS non funzionante. Chiudendoti fuori proprio dalla schermata che ti serve per annullare la modifica.

Devo fare qualcosa in Google Search Console dopo il passaggio a HTTPS?

Sì. Google tratta http:// e https:// come proprietà separate, quindi aggiungi https://yourstore.com come nuova proprietà, non eredita la cronologia della versione HTTP. Aggiorna anche gli URL di Analytics e Merchant Center a HTTPS (un vecchio URL HTTP del flusso prodotti in Merchant Center può far disapprovare i prodotti), rigenera la sitemap in modo che ogni voce sia in HTTPS e aggiorna i webhook di pagamento (PayPal IPN, Stripe, Mollie) all'URL HTTPS. Un webhook rimasto in HTTP è un errore silenzioso nello stato dell'ordine.

Dovrei attivare subito HSTS?

Non come prima cosa. HSTS dice ai browser di rifiutare completamente HTTP per il tuo dominio, il che è positivo, ma un max-age troppo lungo impostato su un sito non ancora completamente pulito può rendere il dominio irraggiungibile, e la direttiva è difficile da ritirare perché i browser la mettono in cache. Verifica prima HTTPS da cima a fondo (Console pulita, procedura di pagamento funzionante, 301 da HTTP, voto A/A+ nel test SSL Labs), poi aggiungi HSTS insieme al resto dell'hardening degli header di sicurezza, non durante la migrazione stessa.