HTTP ( 301 ) Moved Permanently in fase di ricezione notifica

Ciao a tutti,
sono giorni che impazzisco per capire dove stia l’errore che mi ritorna il server dell’agenzia, ovvero:
org.apache.axis2.AxisFault: HTTP ( 301 ) Moved Permanently address : https://26.2.162.231:80

Questa è la mia configurazione di apache2:

<VirtualHost _default_:443>
	SSLEngine On

	# certificato firmato dall'Agenzia (fompato ASCII/PEM)
	SSLCertificateFile "certificates/SDI-XXXXXXX-Server.pem"

	# chiave privata usata per generare la richiesta di certificato
	SSLCertificateKeyFile  "certificates/prod_mykey.key"

	# certificato dellautorità di certificatione dell’agenzia
	SSLCertificateChainFile "certificates/caentrate.der"

	SSLCACertificateFile "certificates/CA_Agenzia_delle_Entrate_all.pem"

	SSLStrictSNIVHostCheck off
	SSLVerifyClient optional
	SSLVerifyDepth 5

	ProxyPreserveHost On

	ServerName test.mioserver.it

	ServerAdmin webmaster@localhost
	DocumentRoot /myroot

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	LogLevel   Info

	<IfModule mod_proxy_fcgi.c>
		<FilesMatch \.php$>
			SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost/"
		</FilesMatch>
	</IfModule>

</VirtualHost>
  • Il file SDI-XXXXXXX-Server.pem l’ho scaricato da http://www.fatturapa.gov.it/ -> Gestire il canale -> Test Interoperabilità (Sdicoop) -> Download file per test

  • Il file prod_mykey.key è la chiave che ho utilizzato per generare il file csr in fase di accreditamento (questa chiave è stata generata sulla macchina di produzione, che è un server completamente diverso rispetto a quello che utilizzo per fare i test)

  • Il file caentrate.der l’ho preso dal KitDitest.zip

  • il file CA_Agenzia_delle_Entrate_all.pem è la concatenazione di caentrate.der e CAEntratetest.cer

Ho sottolineato il fatto che prod_mykey.key sia la chiave generata in produzione, perchè quando ho fatto le prove per inviare la fattura (endpoint ricevi_file fornito dall’agenzia) io utilizzavo il .key della mia macchina di test (essendo in test, non pensavo si dovesse usare la chiave di produzione).

Le fatture riesco ad inviarle, e per l’invio vengono utilizzatii file:

  • CA_Agenzia_delle_Entrate_all.pem
  • prod_mykey.key
  • SDI-XXXXXX-Client.pem

Quindi, CA_Agenzia_delle_Entrate_all.pem e prod_mykey.key li sto già utilizzando all’intetno del processo.

La mini classe php che ho scritto per fare la prova di ricezione notifica è questa:

class SdIRiceviNotificaHandler
{
    const ER01 = 'ER01';

    public function NotificaEsito($parametersIn)
    {
        $xmlString = base64_decode($parametersIn->File);

    }
}

$wsdl = 'certificates/SdIRiceviNotifica_v1.0.wsdl';

$soapServer = new \SoapServer($wsdl);
$soapServer->setClass('SdIRiceviNotificaHandler');
$soapServer->handle();

Questo è quello che trovo nell’access.log di apache:

[16/Nov/2018:10:25:03 +0100] "POST /api/e-invoice/outbound HTTP/1.1" 301 3359

Se servono altre informazioni sono a disposizione, non so piu che test fare…

Scusa ma mi sfugge una cosa (da ignorante) : fai HTTPS su porta 80? non dovrebbe essere : https://26.2.162.231:443 ?

In che senso ? Quell’errore io lo trovo nella sezione “Flussi” del sito http://sdi.fatturapa.gov.it

E’ l’errore che mi risponde quando prova a chiamare l’endpoint che ho indicato in fase di accreditamento (il mio endpoint di test)

L’ip 26.2.162.231 di chi è ?

Non saprei, quello è esattamente l’errore che mi restituisce il server dell’agenzia.

Ho visto che anche altri hanno avuto questo problema, ma non ho capito se e come hanno risolto…

L’unica cosa che mi viene in mente è che in fase di accreditamento quando richiede l’upload dei file CSR (Client e server) io ho caricato in entrambi i campi lo stesso file csr.

Non vorrei che i file da generare fossero stati due, e non mettere in client e server lo stesso file .csr

Provo a fare un altro accreditamento andando a generare due file distinti.

anch’io ho fatto così e non ho avuto nessun problema.

beh, in effetti il tuo server ha risposto con un codice di stato 301, quindi l’errore:

ha senso…

Sicuro che da qualche parte non ci sia un redirect?

Ho fatto un altro tentativo, con i seguenti passaggi:

  • Nuovo accreditamento (annullato il precedente) e generate due chiavi private utilizzate per le due csr (client e server).
  • Cambiato endpoint rispetto al primo accreditamento - ho cambiato proprio il dominio
  • Configurata una macchina “pulita” - nuova installazione e configurato soltanto apache
  • Configurata la porta 80 e tirato su SoapServer per vedere che all’endpoint (di test) rispondesse la wsdl
  • Configurato apache con i certificati ssl
    • SSLCertificateFile “/var/www/certificates/SDI-XXXXXXXXXXX-Server.pem”
    • SSLCertificateKeyFile “/var/www/certificates/server_private.key”
    • SSLCertificateChainFile “/var/www/certificates/caentrate.der”
    • SSLCACertificateFile “/var/www/certificates/CA_Agenzia_delle_Entrate_all.pem”
    • SSLStrictSNIVHostCheck off
    • SSLVerifyClient optional
    • SSLVerifyDepth 5
  • Verificato nuovamente che rispondesse su https (quando vado alla url mi dice che il certificato non è attendibile quindi proseguo ugualmente - da browser).

Risultato: ancora lo stesso 301.

In questo momento l’interfaccia dell’agenzia delle entrate per recuperare il messaggio di errore è impallata (freccia verde che gira su Invio Notifica scarto) e non riesco a dare ulteriori dettagli.

Ciao, sono nella tua stessa situazione, per caso hai risolto?

Ciao si,
praticamente l’errore che avevo fatto era quello di aver mappato l’endpoint su una directory di apache:

Es endpoint: https://test.einvoice.com/ricezione

Nel mio caso “ricezione” era una directory (dove all’interno avevo il file index.php)

Dalla versione 2.2 di apache, se questo “si accorge” che il path è una directory e tu accedi a https://test.einvoice.com/ricezione lui fa un 301 verso https://test.einvoice.com/ricezione/

Anche io ho una directory ricezione/index.php , cosa devo modificare?

grazie

Dunque, lascia la directory con index.php

Nella root del tuo progetto crea un file .htaccess e metti:

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteRule ^ricezione/?$ ./ricezione/index.php [L]
</IfModule>

In questo modo apache quando vede /ricezione usa il rewrite per farti andare alla cartella, piuttosto che interpretare direttamente la cartella.

Una volta che hai messo il rewrite, riavvia apache.

Per vedere se funziona fai cosi (con Chrome):

  • Dal browser, vai sulla tua url con ricezione?wsdl (in questo vedi l’xml)
  • Apri la console, tab Network, abiliti Preserve log, e selezioni Doc
  • Fai refresh della pagina

Se fai ora questa operazione (senza mettere il rewrite), già vedi il 301.

Poi, abiliti il rewrite e metti la regola e ripeti l’operazione. Dal browser devi vedere solo un 200 (singola chiamata, nessun redirect)

ciao , in pratica ho aggiunto il file .htaccess ma non ottengo risultati.
Dalla console di chrome in Doc vedo il 200, ma nella foto sotto

ottento comunque un 301, errore che poi appare sulla notifica su fatturapa.
Grazie

Nel file .htaccess che hai creato (deve essere nella root del progetto, sennò non funziona), scrivici “pippo” come prima riga: ovvero devi fare in modo che il file abbia un errore. (togli delle doppie virgolette ecc… deve essere formalmente sbagliato).

A questo punto ricarica la pagina, se la pagina continua a funzionare vuol dire che l’.htaccess non viene letto.

Fai un giro su stackoverflow per vedere come abilitarlo, una volta che la pagina ti da errrore con “pippo”, toglilo e riprova.

Ho superato l’errore 301, adesso ottengo:
org.apache.axis2.AxisFault: HTTP ( 500 ) Internal Service Error address : https://26.2.162.231:80

Ti è mai successo?

Questo è un errore nel tuo script, se guardi i log di apache vedrai che il sistema ha chiamato il tuo endpoint (con una POST) ed ha ricevuto un 200, ma hai errori nel tuo codice.

Confermo che SdI non segue i redirect 301 e 302. Per questo motivo non puoi utilizzare alcuna rewrite sugli URL. Puoi utilizzare alias o reverse proxy. Inoltre nei messaggi di errore l’URL dell’endpoint viene intenzionalmente rimpiazzato in fase di visualizzazione da quell’IP, ma devi considerarli relativi al tuo endpoint.