Configurare HTTPS in PrestaShop e risolvere i cicli di reindirizzamento

Cosa faremmo noi

Mapperemmo prima il negozio esistente: host, CDN o reverse proxy, versione PrestaShop, domini multinegozio, tema, moduli, integrazioni di pagamento e URL memorizzati nei contenuti. Concorda chi controlla ogni livello e chi può recuperare l'accesso. Una modifica al certificato, una correzione del proxy e una riparazione dei contenuti richiedono responsabili diversi.

Per un passaggio pianificato, esegui una prova su una copia di staging con lo stesso tema e le stesse integrazioni, isolata da email ai clienti, pagamenti reali ed esportazioni per l'evasione degli ordini. Conserva un backup recuperabile e registra le impostazioni attuali di server, proxy e negozio. Poi ripeti le modifiche convalidate in una finestra di produzione concordata, con qualcuno che controlli ordini e callback. Ripristina la configurazione interessata se necessario; sostituire il database di produzione con una copia precedente potrebbe eliminare gli ordini ricevuti dopo quel backup.

Scegli da dove iniziare

Se non è chiaro chi gestisce il percorso della richiesta, PrestaShop Hosting & Infrastructure Audit offre una valutazione e un rapporto scritto; installazione dei certificati e modifiche alla configurazione server sono attività separate.

Installa e verifica il certificato

HTTPS crittografa la connessione e autentica il nome host del server tramite il suo certificato. Domain Validation verifica il controllo di un dominio; Organization Validation ed Extended Validation aggiungono controlli di identità. Queste etichette non selezionano da sole una crittografia TLS più forte.

Un certificato gratuito con validazione del dominio può soddisfare le esigenze del negozio. Scegli copertura, emittente e modalità di rinnovo adatti al tuo hosting e agli eventuali requisiti contrattuali.

• cPanel: usa SSL/TLS Status e la sua azione AutoSSL dove l'hosting la abilita. Controlla fornitore configurato, risultati della validazione del dominio e stato del rinnovo. Consulta la documentazione AutoSSL di cPanel.
• Plesk: usa la gestione dei certificati del dominio e l'estensione Let's Encrypt o dei certificati abilitata. Conferma copertura dei nomi host e rinnovo nel pannello installato; consulta le indicazioni di Plesk sull'estensione dei certificati.
• Server proprio: segui le istruzioni Certbot per il tuo server e sistema operativo. I plugin Apache e Nginx possono ottenere e installare certificati; prova il rinnovo automatico.
• Cloudflare: configura un certificato valido sull'origine e usa Full (strict) per connessioni all'origine crittografate e con certificato validato. Flexible invia HTTP all'origine e può entrare in conflitto con i reindirizzamenti HTTPS.

Prima di modificare PrestaShop, apri direttamente front office e back office tramite HTTPS. Controlla scadenza del certificato, copertura dei nomi host e validità della catena. Includi ogni nome host alternativo raggiunto tramite HTTPS prima del reindirizzamento al nome preferito: il certificato viene controllato prima che quel reindirizzamento possa essere eseguito. Mantieni disponibile l'accesso al server e al database per il recupero.

I browser negoziano normalmente HTTP/2 su TLS, ma server o CDN devono supportarlo. HTTPS da solo non abilita HTTP/2 e non garantisce un miglioramento della velocità.

Abilita i controlli per la tua versione di PrestaShop

Apri Parametri negozio > Generale. Controlla i comandi presenti nella versione installata.

PrestaShop 9.1

La preferenza SSL usa un solo controllo, Abilita SSL, basato su PS_SSL_ENABLED. Quando è abilitato, i controller del front office usano SSL in tutto il front office.

Versioni precedenti con due controlli

PrestaShop 1.7.8 ha Abilita SSL e Abilita SSL su tutte le pagine, basati su PS_SSL_ENABLED e PS_SSL_ENABLED_EVERYWHERE. Dopo aver provato l'accesso HTTPS, abilita SSL, verifica le pagine interessate, poi abilitalo su tutte le pagine e riprova. Controlla l'interfaccia effettiva nelle altre versioni.

Il primo controllo può già influire sull'amministrazione. Abilitare i controlli in fasi non garantisce che l'accesso HTTP al back office resti disponibile.

In Parametri negozio > Traffico & SEO > SEO & URL, controlla le impostazioni degli URL del negozio. I campi dominio contengono nomi host semplici, come example.com, senza schema o percorso. Configura separatamente il percorso di base. Nel multinegozio, esamina i record URL e il contesto del negozio pertinenti.

Rendi coerente il rilevamento dello schema del proxy

Se TLS termina su un reverse proxy, lo schema visto dal browser e la connessione all'origine possono differire. Può verificarsi un ciclo di reindirizzamenti quando l'applicazione vede HTTP e reindirizza un visitatore che sta già usando HTTPS. Per esempio, un bilanciatore accetta HTTPS e inoltra HTTP ad Apache. La regola Apache per TLS diretto riportata sotto vede una richiesta all'origine non sicura e reindirizza allo stesso URL HTTPS pubblico a ogni visita. Inserisci quel reindirizzamento al perimetro o adatta il rilevamento dello schema al proxy attendibile, poi testa sia front office sia amministrazione.

Il metodo legacy Tools::usingSecureMode() controlla le variabili server e legge anche X-Forwarded-Proto. I controlli precedenti sulle variabili server possono influenzarne il risultato. L'amministrazione Symfony usa il rilevamento dello schema sicuro dell'oggetto request e la configurazione dei proxy attendibili.

Nell'amministrazione di PrestaShop 9, imposta PS_TRUSTED_PROXIES sugli indirizzi proxy effettivi come richiesto dalla distribuzione. Fai sovrascrivere al proxy gli header inoltrati, impedisci ai client non attendibili di falsificarli ed esponi uno schema coerente a PHP. Non fidarti di indirizzi proxy arbitrari.

Con Cloudflare, controlla insieme modalità di crittografia e reindirizzamenti dell'origine. Full (strict) valida la connessione all'origine, ma regole contrastanti su host o schema possono comunque creare cicli. Usa i controlli Cloudflare sui cicli di reindirizzamento per esaminare entrambi i livelli.

Aggiungi reindirizzamenti canonici al livello corretto

Dopo aver reso funzionante HTTPS, reindirizza i vecchi URL HTTP al nome host HTTPS scelto. Conserva percorsi e query string. Controlla che tag canonici finali, link interni e sitemap siano coerenti.

Preferisci una regola nel virtual host o al perimetro quando è lì che termina HTTPS. Su Apache, le regole personalizzate vanno fuori dal blocco generato di PrestaShop delimitato da # ~~start~~ e # ~~end~~. La rigenerazione del core conserva i contenuti fuori da quei marcatori e può sostituire le regole al loro interno.

Il seguente esempio è per Apache che termina TLS direttamente, con example.com come host scelto. Non copre un proxy che si collega ad Apache tramite HTTP:

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

Prova con reindirizzamenti temporanei prima di adottare una regola permanente. Dietro un proxy, reindirizza al perimetro oppure configura il server per usare lo schema originale comunicato dal proxy attendibile. Una semplice condizione HTTPS !=on può creare un ciclo in quel contesto.

Su Cloudflare, Always Use HTTPS reindirizza le richieste HTTP al perimetro; configura separatamente Full (strict) per la connessione all'origine. Nginx usa la configurazione dei blocchi server anziché .htaccess. Per ulteriori regole a livello di file, usa la guida a .htaccess di PrestaShop.

Trova e correggi i contenuti misti

Apri i pannelli Console e Network del browser sulle pagine HTTPS. Contenuto misto significa che una pagina sicura richiede una risorsa non sicura. I browser bloccano alcuni tipi di risorsa e possono aggiornare gli altri a HTTPS. Controlla URL ed errore anziché tirare a indovinare da un'impaginazione compromessa.

• Le descrizioni di prodotti e categorie e i contenuti CMS possono contenere URL HTTP assoluti delle immagini.
• I moduli possono registrare URL CSS o JavaScript non sicuri. Usa l'iniziatore della richiesta nel pannello Network per risalire all'origine, poi aggiorna il modulo o chiedi al suo manutentore di correggere la generazione degli URL.
• Il CSS del tema può contenere font o immagini di sfondo HTTP.
• Incorporamenti esterni di video, analisi e social richiedono supporto HTTPS.
• Anche le immagini delle email richiedono URL HTTPS validi per il client email, sebbene il rendering delle email sia separato dai contenuti misti del front office.

Usa editor supportati o una migrazione mirata dopo un backup. Controlla product_lang.description, product_lang.description_short, category_lang.description e cms_lang.content dove pertinente. Limita le modifiche a host, negozio e campi previsti; non eseguire una sostituzione alla cieca nell'intero database.

Per le risorse del front office, usa d'ora in poi HTTPS o URL relativi alla radice appropriati. Usa URL HTTPS assoluti per le immagini delle email. Conferma che gli host di terze parti servano effettivamente l'URL sostitutivo. Gli header di sicurezza non possono riparare un file mancante o un errore del certificato.

Aggiorna servizi esterni e URL generati

Rigenera le sitemap con lo strumento installato, poi esamina gli URL prodotti. Aggiorna pagine di destinazione dei prodotti, feed, destinazioni pubblicitarie e URL del sito configurati per allinearli al sito HTTPS canonico.

In Search Console, una proprietà Dominio esistente copre sia HTTP sia HTTPS. Se usi proprietà con prefisso URL, aggiungi o verifica il prefisso HTTPS secondo necessità. Consulta le indicazioni Google sui tipi di proprietà.

Controlla la gestione dei callback di pagamento con il fornitore e la versione del modulo installati. Aggiorna gli indirizzi webhook o di notifica configurati nel pannello dove l'integrazione li usa. Altre integrazioni inviano l'URL di callback durante la creazione del pagamento, quindi controlla anche una nuova transazione di test oltre al pannello del fornitore.

Completa un pagamento e conferma che il callback cambi lo stato dell'ordine. Una pagina di ritorno nel browser funzionante da sola non basta.

Recupera l'accesso senza modificare ogni negozio

1. Registra l'URL che non funziona, il negozio interessato e se il problema riguarda il front office, l'amministrazione o entrambi. Mantieni disponibili accesso all'hosting, ai file e al database al di fuori del back office non funzionante.
2. Ispeziona la catena di reindirizzamenti con un client senza dati precedenti e registra quale host o livello emette ogni reindirizzamento. Confronta l'URL richiesto con il valore Location di ogni risposta per individuare indirizzi ripetuti o nomi host che si alternano.
3. Controlla errori dei certificati, modalità CDN, regole server e header inoltrati. Modifica il livello che causa il problema, poi ripeti i test prima di modificarne un altro.
4. Se l'imposizione di SSL nell'applicazione impedisce l'accesso, esegui un backup e ispeziona le righe di configurazione pertinenti prima di modificarle. Registra contesto attivo del negozio, identificatori di negozio e gruppo ed eventuale configurazione ereditata per individuare il valore effettivo.

SELECT id_configuration, name, value, id_shop_group, id_shop
FROM ps_configuration
WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

Usa il prefisso effettivo. Modifica solo le righe di configurazione previste per l'ambito interessato e solo le chiavi usate da quella versione. Evita un aggiornamento senza restrizioni su tutti i negozi. Conserva i valori originali e un registro di ogni modifica. Ripristina la configurazione sicura dopo aver corretto la causa, poi testa il negozio interessato e, nel multinegozio, un altro negozio che condivide l'installazione.

Una modifica a livello applicativo non può rimuovere reindirizzamenti del server web o della CDN, correggere gli header proxy o cancellare lo stato HSTS del browser. Tieni il traffico dei clienti fuori da una sessione di recupero non sicura. Svuota la cache tramite Parametri Avanzati > Prestazioni o il comando console supportato con l'ambiente e l'utente applicativo corretti. Riapri l'amministrazione, effettua un ordine di prova e conferma la callback di pagamento prima di riaprire al traffico normale. Riconcilia i pagamenti ricevuti durante l'incidente prima di chiedere ai clienti di riprovare.

Verifica il risultato prima di aggiungere HSTS

1. Controlla sicurezza della connessione e stato del certificato nel browser. L'icona varia secondo browser e versione.
2. Testa homepage, pagine prodotto, categoria, CMS, accesso e checkout con la Console priva di errori. Usa il tema effettivo e i metodi di pagamento abilitati su desktop e mobile, coprendo lingue, valute e negozi che servi.
3. Controlla l'intero back office tramite HTTPS.
4. Testa HTTP e HTTPS per ogni nome host configurato del negozio interessato, inclusi www e non-www dove applicabile. Conferma che gli indirizzi alternativi reindirizzino al nome host HTTPS scelto dal negozio conservando percorsi e query string. L'esempio Apache sopra reindirizza solo HTTP; se un nome host HTTPS alternativo resta accessibile, configura il reindirizzamento dell'host al livello appropriato.
5. Completa un pagamento di prova, inclusa la callback. Associa il riferimento del fornitore all'ordine risultante e allo stato atteso; conserva l'esito per la persona che monitora il passaggio.
6. Testa il rinnovo del certificato, indica il responsabile degli errori di rinnovo e ispeziona l'installazione con uno strumento di verifica TLS come SSL Labs.

curl -I https://example.com/
curl -I http://example.com/

HSTS indica ai browser di usare HTTPS per un periodo memorizzato. Abilitalo dopo che il sito è stabile, con una durata prudente. Aggiungi includeSubDomains o preload solo dopo aver controllato ogni nome host interessato. HSTS rende inefficace un ritorno a HTTP nei browser che hanno memorizzato la politica.

Per i controlli supportati sugli header di sicurezza in Security Revolution, usa la pagina di aiuto del modulo e conferma quali controlli offre la versione installata.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Dove termina TLS, quale livello gestisce i reindirizzamenti canonici e quali indirizzi proxy considera attendibili l'applicazione?
• Quali impostazioni e integrazioni specifiche del negozio sono cambiate e dove sono i risultati dei test in staging e in produzione?
• Cosa ripristina l'accesso se l'amministrazione non funziona e quali limiti derivano da reindirizzamenti in cache o HSTS?
• Chi monitora rinnovi, errori delle callback e nuovi ordini dopo il passaggio e dove sono le istruzioni di recupero?

Domande dei gestori dei negozi

HTTPS può rendere sicuro un negozio compromesso?

HTTPS protegge la connessione al nome host. Non rimuove il codice dannoso dal tema o dai moduli; una pagina compromessa può comunque indirizzare i clienti a un modulo di pagamento fraudolento tramite HTTPS.

Perché un fornitore di pagamenti rifiuta una callback se il browser apre la pagina?

Il fornitore è un client distinto. Controlla il suo errore di consegna, la catena pubblica del certificato, l'autenticazione dell'endpoint e la risposta. Una sessione del browser può essere già autenticata, mentre il fornitore riceve una pagina di accesso o una verifica; anche una notifica reindirizzata può comportarsi diversamente dalla richiesta originale.

Devo sostituire ogni link HTTP nei contenuti?

Individua se si tratta di una risorsa caricata o di un normale link a un altro sito. Correggi le risorse e gli URL canonici del negozio secondo necessità; non riscrivere alla cieca link esterni non pertinenti se la destinazione potrebbe non supportare HTTPS.

Posso mantenere il nome host di staging dopo una prova riuscita?

Usa lo staging per convalidare il metodo, poi applica le impostazioni concordate per il nome host di produzione. Prima di riaprire il negozio in produzione, cerca indirizzi di staging nei contenuti, nelle impostazioni dei moduli, nei feed e negli URL delle callback.