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:
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.
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.
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.
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.