Richiesto aiuto per l’invio dei Certificati di prova dei contatori di Energia Elettrica

Denis.novatronica · 20 Ottobre 2020, 3:17pm

Salve,

Vi scrivo perchè ho esaurito le opzioni a mia disposizione.
È da settimane che provo ad accedere all’ambiente di test del WebService dell’Agenzia delle Dogane senza successo.

Leggendo sul forum dedicato al DAS Elettronico ho imparato nuovi concetti e usando la documentazione sul sito del servizio telematico doganale (sezione contatori)
Ho tentato di collegarmi al WebService delle Dogane.

Il primo scoglio incontrato fu quello rappresentato dall’errore contenuto nel wsdl, perché l’ultima sezione punta al localhost

<wsdl:service name="TaraturaStrumenti">
        <wsdl:port name="TaraturaStrumenti" binding="tns:TaraturaStrumentiSoapBinding">
            <soap:address location="https://localhost:9443/TaraturaStrumentiWeb/services/TaraturaStrumenti"/>
        </wsdl:port>
    </wsdl:service>

Al posto di

<wsdl:service name="TaraturaStrumenti">
        <wsdl:port name="TaraturaStrumenti" binding="tns:TaraturaStrumentiSoapBinding">
            <soap:address location="https://interoptest.agenziadoganemonopoli.gov.it/TaraturaStrumentiWeb/services/TaraturaStrumenti"/>
        </wsdl:port>
    </wsdl:service>

(al quale riesco a collegarmi grazie al certificato dell’azienda del cliente e riesco a farmi rispondere:
{accessPoint/wsdl}TaraturaStrumenti
Hello! This is an Axis2 Web Service !
)

Il secondo scoglio fu quello relativo al collegamento perennemente negato tramite SoapUI con relativo errore " 403 Forbidden - You don’t have permission to access this resource."
Alla fine scoprí che il certificato fu generato con DesktopDogane e non tramite il portale PUDM.

Una volta generato il certificato corretto, ho continuato in tutte le prove effettuate a ricevere errori interni da parte del WebService.
Questa é una videata tipo:
immagine
A sinistra, tutto in riga la richiesta firmata (tramite con lo strumento messo a disposizione da Chilkat).
A destra, la risposta:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault xmlns:axis2ns41="http://schemas.xmlsoap.org/soap/envelope/">
         <faultcode>axis2ns41:Server</faultcode>
         <faultstring>Internal Error</faultstring>
         <detail/>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Il capo ha anche impersonato il cliente abilitando la propria firma digitale sul portale.
Abbiamo quindi firmato digitalmente utilizzando Dike Pro in XADES-Bes, tuttavia la firma generata risulta differente da quella postata sul Das da Matteo il 31 agosto.
Le due firme sono queste:

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504">
        <ds:SignedInfo Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-signedinfo">
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-keyinfo">
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>LEIHrC6q7X8+SVTYS37xxjs1clpfEQqqNinb5ktAM/0=</ds:DigestValue>
            </ds:Reference>
            <ds:Reference Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-ref0" URI="">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>fK98l7TxrEBJ2wzs2DYB4/OpgzZXbP937EhKYQ7k3Tg=</ds:DigestValue>
            </ds:Reference>
            <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-signedprops">
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>w4J8bVdNmdl5OE4vCTm4v6XKjv7EZtucTeezkDTk8zI=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-sigvalue">AAgh3s3M+mfSaO3u+LB3H3mGiBo70EnTsChaKYD6jzlvaF2f8tqZpi5WcJDJ+oa5IGSDZTQRa57ONH7pSYNPZWCNRCMMZEr56WDJbitg4Zoz76mSEnXanXrxLURDQDQGSJlhc96ZcqrVnxzq58cVmLSaPMNGQTKNM156vAZ/iIA=</ds:SignatureValue>
        <ds:KeyInfo Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-keyinfo">
            <ds:X509Data>
                <ds:X509Certificate>MIIE5TCCAs2gAwIBAgIIdqJDNiA164gwDQYJKoZIhvcNAQELBQAwbDELMAkGA1UEBhMCSVQxLDAqBgNVBAoMI0FnZW56aWEgZGVsbGUgRG9nYW5lIGUgZGVpIE1vbm9wb2xpMS8wLQYDVQQDDCZDQSBBZ2VuemlhIGRlbGxlIERvZ2FuZSBlIGRlaSBNb25vcG9saTAeFw0yMDA3MDcwNzMyMDFaFw0yMzA3MDcwNzQxMDBaMGkxCzAJBgNVBAYTAklUMR0wGwYDVQQKDBRBZ2VuemlhIGRlbGxlIERvZ2FuZTEcMBoGA1UECwwTU2Vydml6aW8gVGVsZW1hdGljbzEdMBsGA1UEAwwUR0hCUExBOTBCMTZEMjA1Vi0wMDEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO2aJVO+8LVOAc+49HP53YudDmKkkvV06fouqPzvS49hb6fI9MhYOwN0QU/rL1rvM/W+jqZj8w2Nzvx4DNRlEoOHmxLqXTIhAGVyWPPEKiRHT30h0ln5j5MEbgYS1N0LfhwOPg7UInJIWfNTl7CYDK5Iav06VpIL2SDtTrt2J4FNAgMBAAGjggEQMIIBDDAfBgNVHSMEGDAWgBRzxLCNEFq74WjxF6PpEXx7/v5KTTCBuQYDVR0fBIGxMIGuMIGroIGooIGlhoGibGRhcDovL2NhZHMuZG9nYW5lLmZpbmFuemUuaXQvQ049Q0ElMjBBZ2VuemlhJTIwZGVsbGUlMjBEb2dhbmUlMjBlJTIwZGVpJTIwTW9ub3BvbGksTz1BZ2VuemlhJTIwZGVsbGUlMjBEb2dhbmUlMjBlJTIwZGVpJTIwTW9ub3BvbGksQz1JVD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0MB0GA1UdDgQWBBSIovjOhfoy3UAdoawU+pIp1yqOxDAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBAAB9guAsnO5qzX2TRa+LWby2KYV7LneTxLXIAEhdbogr7ys8kaKgfyX55sGT6uDyllF7oJ/3SSHwZ9rX138U6jifbReTGllaO8NzAXzz5ZvPEb28aZBNb6n4jO7b/G9v/Ug2eKAbfgBymeViQkzoHQfwP3BU7pcjZOnCJX4nu/0tEelUSBCNMNDJ4yOuVWTkqwYoAH1LwKEEtJeIu6wf/EQO7Fgq+Nk70G9D5b16yUkSUm+z7ya7BNgZAV9cdTWuBOVX1FzemkyQGBH/cSr0ZJe1Oi/QLsWMmFz4XKg93xeYuu9XVM5obveKPObwQUjJ+yCH4zhlUTtL8K0NLYgkqurbnt70ymH9VZcoU9EGmKaMCVQi2OHTUc5K1qlhYLvcNpZl//YpE0EYO8yiaNycP2QDX7dwmhQ70ZnrTiG09XEXl+8woNCjMBjlR9SUuJykRDRXl56oIKFESAHnw134CZTk42sUt3RFiZFUNzWhhCaJ0/GDXc4DC4hrI+OTngP8dEyDR9PxHFrfSMJsdfjZ9gGeKIvBqnxwu/Qp5Qwp3GuJSSsYQxJ+YsaVCCvE1N2dWCMoBT5+rYgWLfXoVxcVRTUoH9hLtlUWWSKEfDCai0A/4M3/thb3Sk/RloK7FYGu5w+0LJNAbfXnggOqQnH89GnvV7xIvPRGKrxZ5fIthWol</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
        <ds:Object>
            <xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
                xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#" Target="#xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504">
                <xades:SignedProperties Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-signedprops">
                    <xades:SignedSignatureProperties>
                        <xades:SigningTime>2020-10-20T13:31:08Z</xades:SigningTime>
                        <xades:SigningCertificate>
                            <xades:Cert>
                                <xades:CertDigest>
                                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                                    <ds:DigestValue>527shCt883krG3S7D7fF+5fR4gWjghKeHYASUk3Hmks=</ds:DigestValue>
                                </xades:CertDigest>
                                <xades:IssuerSerial>
                                    <ds:X509IssuerName>CN=CA Agenzia delle Dogane e dei Monopoli, O=Agenzia delle Dogane e dei Monopoli, C=IT</ds:X509IssuerName>
                                    <ds:X509SerialNumber>8548468942450322312</ds:X509SerialNumber>
                                </xades:IssuerSerial>
                            </xades:Cert>
                        </xades:SigningCertificate>
                    </xades:SignedSignatureProperties>
                </xades:SignedProperties>
            </xades:QualifyingProperties>
        </ds:Object>
    </ds:Signature>

Dike indenta, mentre ChilKat comprime (come da configurazione)

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504">
        <ds:SignedInfo Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-signedinfo">
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-keyinfo">
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>1u7Z3ep7e/dVuCeWtpPudJmc5pt8QvcyQRqvBbKdxZ0=</ds:DigestValue>
            </ds:Reference>
            <ds:Reference Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-ref0" URI="">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>MAjZg/htspl6igpJ3mu05qbEwEX4OTlPwP3/Nh26KOc=</ds:DigestValue>
            </ds:Reference>
            <ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-signedprops">
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>MIjGHb8PAhWqrTIzPPoZdilFYLel7pX7C1MdIAcbmHA=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-sigvalue">(Signature Value)</ds:SignatureValue>
        <ds:KeyInfo Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-keyinfo">
            <ds:X509Data>
                <ds:X509Certificate>(Certificate)</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
        <ds:Object>
            <xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
                xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#" Target="#xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504">
                <xades:SignedProperties Id="xmldsig-6f4b994a-7191-4bb1-ab3c-17549515b504-signedprops">
                    <xades:SignedSignatureProperties>
                        <xades:SigningTime>2020-08-31T12:29:38Z</xades:SigningTime>
                        <xades:SigningCertificate>
                            <xades:Cert>
                                <xades:CertDigest>
                                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                                    <ds:DigestValue>adQy98MLeN26i7C41WgFaAKb8YY/yJximVGdk6mUkPQ=</ds:DigestValue>
                                </xades:CertDigest>
                                <xades:IssuerSerial>
                                    <ds:X509IssuerName>CN=InfoCert Servizi di Certificazione 2, SERIALNUMBER=(Serial Number), OU=Ente Certificatore, O=INFOCERT SPA, C=IT</ds:X509IssuerName>
                                    <ds:X509SerialNumber>(Serial Number)</ds:X509SerialNumber>
                                </xades:IssuerSerial>
                            </xades:Cert>
                        </xades:SigningCertificate>
                    </xades:SignedSignatureProperties>
                </xades:SignedProperties>
            </xades:QualifyingProperties>
        </ds:Object>
    </ds:Signature>

In ogni caso la risposta è sempre la medesima.
Queste sono le richieste che ho fatto al WebService:

Test

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://xsd.taraturastrumenti.domest.dogane.finanze.it">
    <soapenv:Header/>
    <soapenv:Body>
        <xsd:dispatcherRequest>
            <messaggio>
                <serviceID>TEST</serviceID>
            </messaggio>
        </xsd:dispatcherRequest>
    </soapenv:Body>
  <!—<ds:Signature>… --!>
</soapenv:Envelope>

Contatori C1

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://xsd.taraturastrumenti.domest.dogane.finanze.it">
    <soapenv:Header/>
    <soapenv:Body>
        <xsd:dispatcherRequest>
            <messaggio>
                <serviceID>CONTATORE</serviceID>
                <xmlList>
                    <XmlDTO>
                        <xml>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q2VydGlmaWNhdG9DMT48U2Vydml6aW8+PHRpcG9NZXNzYWdnaW8+QTE8L3RpcG9NZXNzYWdnaW8+PC9TZXJ2aXppbz48TGFib3JhdG9yaW8+PGNmUGl2YUxhYm9yYXRvcmlvPnN0cjEyMzQwMDAwPC9jZlBpdmFMYWJvcmF0b3Jpbz48aWRMYWJvcmF0b3Jpbz4xMjM8L2lkTGFib3JhdG9yaW8+PC9MYWJvcmF0b3Jpbz48VmVyaWZpY2E+PG51bVZlcmlmaWNhPnN0cjEyMzQ8L251bVZlcmlmaWNhPjxkYXRhVmVyaWZpY2E+MjAxMi0xMi0xMzwvZGF0YVZlcmlmaWNhPjwvVmVyaWZpY2E+PFJpY2hpZWRlbnRlPjxjb2RpY2VBY2Npc2E+c3RyMTIzNDwvY29kaWNlQWNjaXNhPjxjZlBpdmFSaWNoaWVkZW50ZT5zdHIxMjM0PC9jZlBpdmFSaWNoaWVkZW50ZT48aW5kaXJpenpvPnN0cjEyMzQ8L2luZGlyaXp6bz48Y2l2aWNvPnN0cjEyMzQ8L2Npdmljbz48cHJvdmluY2lhPnN0cjEyMzQ8L3Byb3ZpbmNpYT48Y29tdW5lPnN0cjEyMzQ8L2NvbXVuZT48Y2FwPnN0cjEyMzQ8L2NhcD48L1JpY2hpZWRlbnRlPjxDYW1waW9uZT48bWFyY2FDb250Q2FtcGlvbmU+c3RyMTIzNDwvbWFyY2FDb250Q2FtcGlvbmU+PG1vZGVsbG9Db250Q2FtcGlvbmU+c3RyMTIzNDwvbW9kZWxsb0NvbnRDYW1waW9uZT48bnVtU2VyaWVDb250Q2FtcGlvbmU+c3RyMTIzNDwvbnVtU2VyaWVDb250Q2FtcGlvbmU+PG51bUNlcnRpZmljYXRvPnN0cjEyMzQ8L251bUNlcnRpZmljYXRvPjxlbWVzc29EYT5zdHIxMjM0PC9lbWVzc29EYT48L0NhbXBpb25lPjxDb250YXRvcmU+PG1hdHJpY29sYT5zdHIxMjM0PC9tYXRyaWNvbGE+PG1hcmNhPnN0cjEyMzQ8L21hcmNhPjxtb2RlbGxvPnN0cjEyMzQ8L21vZGVsbG8+PG1pZD5zdHIxMjM0PC9taWQ+PGNvc3RJbnRlZ3JDb250YXRvcmU+c3RyMTIzNDwvY29zdEludGVnckNvbnRhdG9yZT48Y2xhc3NlQXR0aXZhPnN0cjEyPC9jbGFzc2VBdHRpdmE+PHRpcG9JbnNlcnppb25lPnN0cjEyMzQ8L3RpcG9JbnNlcnppb25lPjx1bUZyZXF1ZW56YT5IejwvdW1GcmVxdWVuemE+PGZyZXF1ZW56YT5zdHIxMjM0PC9mcmVxdWVuemE+PHVtVGVuc2lvbmU+VjwvdW1UZW5zaW9uZT48dGVuc2lvbmU+c3RyMTIzNDwvdGVuc2lvbmU+PHVtQ29ycmVudGU+QTwvdW1Db3JyZW50ZT48Y29ycmVudGU+c3RyMTIzNDwvY29ycmVudGU+PGtDb250YXRvcmU+MTIzNDU8L2tDb250YXRvcmU+PGtDb250YXRvcmVEZW5vbWluYXRvcmU+Pz8/PC9rQ29udGF0b3JlRGVub21pbmF0b3JlPjxpbnRlcmlJbnRlZ3JhdG9yZT4xMjM0NTwvaW50ZXJpSW50ZWdyYXRvcmU+PGRlY2ltYWxpSW50ZWdyYXRvcmU+MTIzPC9kZWNpbWFsaUludGVncmF0b3JlPjx1bml0YU1pc3VyYUludGVncmF0b3JlPnN0cjEyMzQ8L3VuaXRhTWlzdXJhSW50ZWdyYXRvcmU+PC9Db250YXRvcmU+PFRhcmF0dXJhPjx0ZW5zaW9uZU1pc3VyYT5zdHIxMjM0PC90ZW5zaW9uZU1pc3VyYT48dW1UZW1wZXJhdHVyYT5zdHIxMjM0PC91bVRlbXBlcmF0dXJhPjx0ZW1wZXJhdHVyYT4/Pz88L3RlbXBlcmF0dXJhPjx1bVVtaWRpdGE+c3RyMTIzNDwvdW1VbWlkaXRhPjx1bWlkaXRhPj8/PzwvdW1pZGl0YT48VG90YWxpenphdG9yZT48dGlwb1JlZ2lzdHJvPnN0cjEyMzQ8L3RpcG9SZWdpc3Rybz48bGV0dHVyYUZpbmFsZT5zdHIxMjM0PC9sZXR0dXJhRmluYWxlPjwvVG90YWxpenphdG9yZT48VG90YWxpenphdG9yZUZhc2NlPjx0aXBvUmVnaXN0cm8+c3RyMTIzNDwvdGlwb1JlZ2lzdHJvPjxsZXR0dXJhRmluYWxlPnN0cjEyMzQ8L2xldHR1cmFGaW5hbGU+PC9Ub3RhbGl6emF0b3JlRmFzY2U+PC9UYXJhdHVyYT48RXJyb3JlPjxwdW50aURpTWlzdXJhPjEyMzwvcHVudGlEaU1pc3VyYT48ZmFzZT5SU1Q8L2Zhc2U+PGNvcnJlbnRlPnN0cjEyMzQ8L2NvcnJlbnRlPjxpbG5QZXJjPj8/PzwvaWxuUGVyYz48ZmRwVGlwbz5zdHIxMjM0PC9mZHBUaXBvPjxmZHBWYWxvcmU+MTIzLjQ1PC9mZHBWYWxvcmU+PGVycm9yZU1pc3VyYXRvQXBvcz4/Pz88L2Vycm9yZU1pc3VyYXRvQXBvcz48ZXJyb3JlTWlzdXJhdG9BbmVnPj8/PzwvZXJyb3JlTWlzdXJhdG9BbmVnPjxlcnJvcmVMaW1pdGU+Pz8/PC9lcnJvcmVMaW1pdGU+PGlkTm90YT5zdHIxMjwvaWROb3RhPjwvRXJyb3JlPjxTdWdnZWxsaT48blN1Z2dlbGxpPj8/PzwvblN1Z2dlbGxpPjxvcGVyYXppb25lPnN0cjEyMzQ8L29wZXJhemlvbmU+PG5Qb3NpemlvbmVEZXNjcml6aW9uZT5zdHIxMjM0PC9uUG9zaXppb25lRGVzY3JpemlvbmU+PC9TdWdnZWxsaT48UHJvdmVGaW5hbGk+PGNvbnRyb2xsb051bWVyYXRvcmU+c3RyMTIzNDwvY29udHJvbGxvTnVtZXJhdG9yZT48cHJvdmFBdnZpYW1lbnRvPnN0cjEyMzQ8L3Byb3ZhQXZ2aWFtZW50bz48cHJvdmFNYXJjaWFBdnVvdG8+c3RyMTIzNDwvcHJvdmFNYXJjaWFBdnVvdG8+PC9Qcm92ZUZpbmFsaT48Tm90ZT48bk5vdGE+c3RyMTI8L25Ob3RhPjx0ZXN0b05vdGE+c3RyMTIzNDwvdGVzdG9Ob3RhPjwvTm90ZT48RmlybWE+PHJlc3BvbnNhYmlsZUNlbnRybz5zdHIxMjM0MDAwMDAwMDAwPC9yZXNwb25zYWJpbGVDZW50cm8+PC9GaXJtYT48L0NlcnRpZmljYXRvQzE+</xml>
                    </XmlDTO>
                </xmlList>
            </messaggio>
        </xsd:dispatcherRequest>
    </soapenv:Body>

Ottengo sempre la stessa risposta.

SoapUI al Validate(Alt+V) si lamenta dell’elemento signature:

line10: Element not allowed: Signature@http://www.w3.org/2000/09/xmldsig# in element Envelope@http://schemas.xmlsoap.org/soap/envelope/

Se provassi a rimuovere per intero la firma digitale otterrei:

lo stesso identico messaggio di risposta da parte del WebService
la Validate che si lamenta della mancanza di alcuni campi che secondo la documentazione dovrebbero essere opzionali nel serviceId=TEST
Questo é ció che genera SoapUI alla creazione di una nuova richiesta:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://xsd.taraturastrumenti.domest.dogane.finanze.it">
   <soapenv:Header/>
   <soapenv:Body>
      <xsd:dispatcherRequest>
         <messaggio>
            <inputObj>?</inputObj>
            <outputObj>?</outputObj>
            <serviceID>?</serviceID>
            <xmlList>
               <!--Zero or more repetitions:-->
               <XmlDTO>
                  <xml>cid:1600967952886</xml>
               </XmlDTO>
            </xmlList>
         </messaggio>
      </xsd:dispatcherRequest>
   </soapenv:Body>
</soapenv:Envelope>

Voi avreste qualche idea o consiglio?

Vi ringrazio molto.

meltigel · 20 Ottobre 2020, 3:32pm

Devi fare attenzione al certificato di firma che utilizzi. Se tramite Dyke o File Protector ispezioni i certificati installati sulla CNS o sul Token USB, molto probabilmente ne vedresti due. Al 99% (perchè è successo lo stesso a me con il DAS) stai usando il certificato sbagliato. Se utilizzi Chilkat, segui pari pari l’esempio postato sul loro sito in base al linguaggio che utilizzi, e dovrebbe andare.

Denis.novatronica · 21 Ottobre 2020, 8:30am

Ciao Giuseppe,
Gentilissimo !

Grazie a te ora so qualcosa in piú.
Purtroppo non ci sono ancora riuscito…

Sto scrivendo un client in C# e pensavo di usare Chilkat per la “compilazione” della risposta, in modo da poter generare firme per le richieste successive. Prima peró mi servirebbe un modello in grado di generare una richiesta accettabile e tra i vari esempi non ho capito quale potrebbe esserci utile.
Ho provato con Dike, File Protector e anche a generare con il tool l’xml firmato con la stessa struttura che aveva postato Matteo utilizzando il certificato.p12 che mi aveva girato il cliente, ma ho ottenuto sempre lo stesso errore.

Con File Protector 6 abbiamo verificato la presenza di due certificati sulla chiavetta:

Il certificato CNS, il quale genera un XML non valido,
il certificato DS3 che ha passato la “Verifica” di File Protector.

Ho utilizzato le seguenti impostazioni per firmare gli XML
immagine
E questo é il risultato

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://xsd.taraturastrumenti.domest.dogane.finanze.it">
   <soapenv:Header></soapenv:Header>
   <soapenv:Body>
      <xsd:dispatcherRequest>
         <messaggio>
            <serviceID>TEST</serviceID>
         </messaggio>
      </xsd:dispatcherRequest>
   </soapenv:Body><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signer-T-1603265264451">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
<ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#SignedProperties-Signer-T-1603265264451">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>l5JtHH9hGz/XSJfJemJAdnaXAmJ8Kt1FJtd6GhNp3JM=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<dsig-xpath:XPath xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2" Filter="subtract">/descendant::ds:Signature</dsig-xpath:XPath>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>qVfk+x7dWqVMP7CPdag8GsfujSCe95HmHhUElGWXqCc=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#KeyInfo-Signer-T-1603265264451">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:DigestValue>f66dBvzQR1PbqyS4C878HIF7pUATSIvU9NUfBXlm5NQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
vVhT6Uj7RkqDqB+hSL6uSe98Z4gEm/8+4OtIi0y7CzG0ImjZC9BKs8kS//XDe3xOe4BqK1JRqtnq
Plgk1HNOgrINE6OlG5cW5yo5YeGdYYKCiprw4oLsUGgRIs7dBEkJHrWu+s4JimxtCZIvyzi/lmAs
81tyBB8b2LJodnEBIIGwvPHuuxNzTfxnEwZZEqzLHu5Is+XuFyptwrARdHimSbxUYWAJDO5u8HVU
5ItcjRu2kOjh/nNfQ6aOst+4P7nqS0DSsJrDZ9Jv2k44HrTAVcsuPNYFAl0KHmpumazJzi5cCk5t
If3W+NCWWOujuDaVKQZuvJSpOAHPDDwPNzF09g==
</ds:SignatureValue>
<ds:KeyInfo Id="KeyInfo-Signer-T-1603265264451">
<ds:X509Data>
<ds:X509Certificate>
MIIHtzCCBp+gAwIBAgIEAOuqKjANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMCSVQxFTATBgNV
BAoMDElORk9DRVJUIFNQQTEiMCAGA1UECwwZQ2VydGlmaWNhdG9yZSBBY2NyZWRpdGF0bzEUMBIG
A1UEBRMLMDc5NDUyMTEwMDYxJTAjBgNVBAMMHEluZm9DZXJ0IEZpcm1hIFF1YWxpZmljYXRhIDIw
HhcNMTkxMDI0MDc1OTU0WhcNMjIxMDI0MDAwMDAwWjB7MQswCQYDVQQGEwJJVDENMAsGA1UEBAwE
Tk9WQTEfMB0GA1UEBRMWVElOSVQtTlZPREdJNzlBMDlEMjA1UjETMBEGA1UEAwwKTk9WQSBESUVH
TzEXMBUGA1UELhMOMjAxOTcxMTMyMDM1NjExDjAMBgNVBCoMBURJRUdPMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAxVJGtNIS6YJWyYHtbaLLArRbFoMmrNLP7jA2J/Mt8xOG8BKBCOQe
LyZzF0DfwO8vn19AWWXbqak7p/rr5GjECMrqoHlB9ML+7giXjNV8Fx5a510mB6WFrXR5YDhoCEby
m8aistHUAgz5LsgXPe4w9WmZeD/JW6YsewVKOlQmbKVn6BfMDeN2mVnZ/UJW2XI+BclQcEn0Q6dk
q4oKgqs5g9rtysMPK/w21295rp0s/LL5LSX9svO1XsO4mQ+0i8PPjZB3GuQPy6MxUVFK9/cuSvJo
7jVAA9Rj6Z36DSBnBWcBBAM4XPI1GiVvwozZaEP2f+skG1ACUD30xRc2IL0D0wIDAQABo4IENjCC
BDIwCQYDVR0TBAIwADAlBgNVHRIEHjAcgRpmaXJtYS5kaWdpdGFsZUBpbmZvY2VydC5pdDCB5wYD
VR0fBIHfMIHcMDKgMKAuhixodHRwOi8vY3JsLmluZm9jZXJ0Lml0L2NybHMvZmlybWEyL0NSTDM0
LmNybDCBpaCBoqCBn4aBnGxkYXA6Ly9sZGFwLmluZm9jZXJ0Lml0L2NuJTNESW5mb0NlcnQlMjBG
aXJtYSUyMFF1YWxpZmljYXRhJTIwMiUyMENSTDM0LG91JTNEQ2VydGlmaWNhdG9yZSUyMEFjY3Jl
ZGl0YXRvLG8lM0RJTkZPQ0VSVCUyMFNQQSxjJTNESVQ/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz
dDBuBggrBgEFBQcBAQRiMGAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnNjLmluZm9jZXJ0Lml0
LzA1BggrBgEFBQcwAoYpaHR0cDovL2NlcnQuaW5mb2NlcnQuaXQvY2EyL2Zpcm1hMi9DQS5jcnQw
gegGA1UdIASB4DCB3TBPBgYrTCQBASAwRTBDBggrBgEFBQcCARY3aHR0cDovL3d3dy5maXJtYS5p
bmZvY2VydC5pdC9kb2N1bWVudGF6aW9uZS9tYW51YWxpLnBocDAIBgYrTBgBAQIwCQYHBACL7EAB
AjB1BgQrTBAGMG0wawYIKwYBBQUHAgIwXwxdUXVlc3RvIGNlcnRpZmljYXRvIHJpc3BldHRhIGxl
IHJhY2NvbWFuZGF6aW9uaSBwcmV2aXN0ZSBkYWxsYSBEZXRlcm1pbmF6aW9uZSBBZ2lkIE4uIDEy
MS8yMDE5MIGEBggrBgEFBQcBAwR4MHYwCAYGBACORgEBMAgGBgQAjkYBBDALBgYEAI5GAQMCARQw
EwYGBACORgEGMAkGBwQAjkYBBgEwPgYGBACORgEFMDQwMhYsaHR0cHM6Ly93d3cuZmlybWEuaW5m
b2NlcnQuaXQvcGRmL1BLSS1EUy5wZGYTAmVuMA4GA1UdDwEB/wQEAwIGQDAkBgNVHREEHTAbgRlk
aWVnby5ub3ZhQG5vdmF0cm9uaWNhLml0MCgGA1UdCQQhMB8wHQYIKwYBBQUHCQExERgPMTk3OTAx
MDkwMDAwMDBaMIGyBgNVHSMEgaowgaeAFJPdIfwD0BUKcq2jzNWaCZ04i53poYGLpIGIMIGFMQsw
CQYDVQQGEwJJVDEVMBMGA1UECgwMSU5GT0NFUlQgU1BBMSIwIAYDVQQLDBlDZXJ0aWZpY2F0b3Jl
IEFjY3JlZGl0YXRvMRQwEgYDVQQFEwswNzk0NTIxMTAwNjElMCMGA1UEAwwcSW5mb0NlcnQgRmly
bWEgUXVhbGlmaWNhdGEgMoIBATAdBgNVHQ4EFgQUSNxkGZjfJFTc+W83d1XBQTZm/qYwDQYJKoZI
hvcNAQELBQADggEBAKfohLbxKkFJyTy3Psl2iCAvkp898EEbLk55SzHytEUF3JgKILcVpmW2hlbx
KPN0e/bzHNAmRbf0Cm923UNNkY5uVyCrBrhgcIMtUUN+KCLRKEE9n3WMfnNbGHu6XmTF0PV4GXPE
4MC+l+5Y1aPnuKT0izSXLQV3BF6szoClYfEeiIZcg86PI2Oi8sw+n5+ffA773PSqkXQBk00ch6yk
K/ll/0aoufvI6isMjr5ByvuUcKLfiFdmrPkALPsrRcu2VcPQenhJkjcJL7czZhkmaYXbASUHqBOV
wr3gpJ1Qf9kPiqwHmQ+a6380z9LOE2LKwlZWnPH+i9+ow6ZsQGCZkUA=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object>
	<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#Signer-T-1603265264451">
		<xades:SignedProperties Id="SignedProperties-Signer-T-1603265264451">
			<xades:SignedSignatureProperties>
				<xades:SigningTime>2020-10-21T09:27:44+02:00</xades:SigningTime>
				<xades:SigningCertificate>
					<xades:Cert>
						<xades:CertDigest>
							<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
							<ds:DigestValue>+BwBkHn1MjMEC36xsTmM9OHuvujU2t6G6WhSP09ATrg=</ds:DigestValue>
						</xades:CertDigest>
						<xades:IssuerSerial>
							<ds:X509IssuerName>C=IT,O=INFOCERT SPA,OU=Certificatore Accreditato,SERIALNUMBER=07945211006,CN=InfoCert Firma Qualificata 2</ds:X509IssuerName>
							<ds:X509SerialNumber>15444522</ds:X509SerialNumber>
						</xades:IssuerSerial>
					</xades:Cert>
				</xades:SigningCertificate>
			</xades:SignedSignatureProperties>
		</xades:SignedProperties>
	</xades:QualifyingProperties>
</ds:Object>
</ds:Signature>
</soapenv:Envelope>

Purtroppo con SOAPUI ho ricevuto lo stesso errore di sempre (internal server error);

Non vorrei che il problema fosse legato al fatto che, se provo a validare con SoapUI l’XML precedente, lui si lamenta dando il seguente errore:

line10: Element not allowed: Signature@http://www.w3.org/2000/09/xmldsig# in element Envelope@http://schemas.xmlsoap.org/soap/envelope/

Dici che potrebbe influire sull’esito dell’operazione ?

meltigel · 21 Ottobre 2020, 8:44am

Non ti so aiutare con SOAP, perchè lo utilizzo pochissimo. Io sto sviluppando un cliente per il DAS elettronico, ma il principio di base è lo stesso. Se provo ad inviare una richiesta SOAP la risposta è positiva, perchè ho installato nel sistema sia il certificato lato client (quello generato da PUDM) e sia lato server (si scarica dalla stessa schermata, dovrebbe essere CADoganeMonopoli.pem). Prova ad installare entrambi i certificati, e lancia una richiesta da SOAP senza la firma (vedo che mandi TEST, in teoria non necessita di firma, quello è giusto un test per vedere come risponde il server). Oppure dovresti provare ad utilizzare la web service (non so se per i contatori esiste, ma credo di si)…

Denis.novatronica · 22 Ottobre 2020, 7:23am

Grazie dell’aiuto, abbiamo provato ad installare sul sistema entrambi i certificati (sia quello client ottenuto tramite PUDM che quello server CADoganeTest.pem)

Direi che il certificato client è corretto in quanto il WebService ha smesso di rispondere 403.

Quello che non capisco è che, inviando una richiesta TEST firmata o non firmata la risposta è sempre la medesima (Error code 500 - Internal server error)

Con SoapUI questa è la risposta

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault xmlns:axis2ns88="http://schemas.xmlsoap.org/soap/envelope/">
         <faultcode>axis2ns88:Server</faultcode>
         <faultstring>Internal Error</faultstring>
         <detail/>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

invece di una risposta formattata secondo il file E0.xsd (esito) come riportato nella documentazione sul sito delle dogane (https://www.adm.gov.it/portale/documents/20182/2826878/Manuale+Operativo+-+Certificati+di+Prova+contatori+Energia+Elettrica_27042020.pdf/12c034d8-2dba-427e-866a-f2ff18716189)

Analogamente, collegandoci all’endpoint remoto da Visual Studio riesco a collegarmi, generare le classi necessarie all’interazione ed utilizzarle


var client = new TaraturaStrumentiClient();
                client.ClientCredentials.ClientCertificate.Certificate = uidCert;
                var request = new dispatcherRequest();
                request.messaggio = new MessageDTO();
                request.messaggio.serviceID = "TEST";
                var resp = client.accessPoint(request);

ma anche in questo caso ottengo lo stesso errore.

Per inviare documenti firmati ho utilizzato un altro approccio al fine di eliminare delle varibili dal problema: firmo esternamente al programma gli XML (con Dike Pro, File protector, Chilkat) poi lo inietto in una envelope e invio il tutto con una WebRequest

                var _url = "https://interoptest.agenziadoganemonopoli.gov.it/TaraturaStrumentiWeb/services/TaraturaStrumenti";
                var _action = "http://accessPoint.taraturastrumenti.domest.dogane.finanze.it/wsdl/TaraturaStrumenti";
                XmlDocument soapEnvelopeXml = CreateSoapEnvelope();
                HttpWebRequest webRequest = CreateWebRequest(_url, _action);
                InsertSoapEnvelopeIntoWebRequest(soapEnvelopeXml, webRequest);
                IAsyncResult asyncResult = webRequest.BeginGetResponse(null, null);

Abbiamo provato con una miriade di versioni diverse di file firmati (con la nostra chiavetta USB, con quella del cliente, con i certificati .p12 di firma che il cliente ci ha fornito…)

Con le chiavette USB troviamo sempre 2 certificati ma solo uno (DS3) è utilizzabile per firmare i documenti.

Inoltre ho preso il file “CADoganeTest.pem” ma da quanto ho capito essendo il certificato del server non continene (per ovvie ragioni) la chiave privata di Agenzia delle Dogane, quindi non capisco come usarlo anche se l’ho installato nel sistema.

Non so se l’internal Server Error sia legato al fatto che il WebService (magari) non implementa questi metodi anche se la documentazione dice il contrario, oppure lo implementa ma si aspetta un messaggio in un formato diverso da quello documentato.

Purtroppo l’errore troppo generico (Internal Server Error) non aiuta a diagnosticare quale sia il reale problema e come porvi rimedio.

Per curiosità: quale linguaggio di programmazione utilizzi per l’implementazione del tuo client DAS?
Come usi i certificati e le firme?

meltigel · 22 Ottobre 2020, 9:43am

Uso C#. Per la firma, le librerie Chilkat sono le migliori, a mio avviso (costano 290 dollari una tantum, ma consentono di fare un sacco di cose). Per i certificati, mi creo una variabile di tipo X509Certificate con il certificato di prova, una variabile di tipo Uri con l’endpoint (mediante la quale si deve creare un EndpointAddress) e un binding. Il binding deve avere Security.Mode = Transport e ClientCredentialType = Certificate.
Poi mi creo una variabile di tipo MovimentazioniDAS (che deriva dall’importazione del WSDL) passando come parametri il binding e l’endpoint. Infine MovimentazioniDAS.ClientCredentials.ClientCertificate.Certificate = il mio certificato creato all’inizio.

MovimentazioniDAS contiene il metodo Process che consente l’invio del messaggio.

Ti consiglio di inserire queste due righe:
ServicePointManager.ServerCertificateValidationCallback = (object se, X509Certificate cert, X509Chain chain, SslPolicyErrors sslerror) => true;

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

La prima serve a saltare il controllo del certificato del Server (se nel caso non aggiornano le firme o altro), la seconda a forzare la comunicazione HTTPS.

Denis.novatronica · 22 Ottobre 2020, 1:54pm

In effetti, per quanto concerne la sicurezza e l’autenticazione informatica sono il top;
Ho adattato il codice come mi hai suggerito e questa é la nuova versione:

try
{
    ServicePointManager.ServerCertificateValidationCallback = (se, cert, chain, sslErrors) => true;
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
    Uri uri = new Uri(
        "https://interoptest.agenziadoganemonopoli.gov.it:443/TaraturaStrumentiWeb/services/TaraturaStrumenti");
    EndpointAddress endPoint = new EndpointAddress(uri);
    WSHttpBinding binding = new WSHttpBinding
    {
        Security =
        {
            Mode = SecurityMode.Transport,
            Transport = {ClientCredentialType = HttpClientCredentialType.Certificate}
        }
    };

    TaraturaStrumentiClient client = new TaraturaStrumentiClient(binding, endPoint);

    X509Certificate2 certificate = new X509Certificate2(fileName, password);
    client.ClientCredentials.ClientCertificate.Certificate = certificate;

    dispatcherRequest request = new dispatcherRequest {messaggio = new MessageDTO {serviceID = "TEST"}};
    dispatcherResponse response = client.accessPoint(request);
}
catch (Exception ex)
{
    Console.WriteLine(ex);
}

(TaraturaStrumentiClient é l’equivalente di MovimentazioniDAS generato con Visual Studio.)

La risposta questa volta é stata: “(400) Bad Request”.
(sempre meglio di “(500)Internal server error” !)

Secondo te cosa potrebbe causarla ?

Altro dubbio: come applichi la firma all’oggetto MovimentazioniDAS ?
perché con Chilkat si genera un xml firmato partendo dall’xml da firmare e la firma digitale,
ma poi come si puó spedire con questa implementazione il documento firmato ?
Nel senso, dal Das non é necessario applicare la firma digitale (Xades-Bes) ad una qualunque richiesta ?

Proprio per questo motivo utilizzavo SoapUI, perché cosí potevo inviare documenti firmati al WebService (l’unico modo che ho trovato in C# é tramite l’HttpWebRequest postato sopra)

meltigel · 22 Ottobre 2020, 2:05pm

Per prima cosa, prova a cambiare il binding in BasicHttpBinding.
Poi, quali sono i metodi di TaraturaStrumentiClient? Perchè per il DAS c’è il metodo Process, che accetta un parametro di tipo “Richiesta”, che a sua volta è una List di “RichiestaData”, che a sua volta vuole un “dichiarante”(la P.IVA di chi genera la richiesta) e un byte[], che è l’XML firmato. Viene da sè che prima di richiamare questo metodo ne ho scritto un altro che prende l’XML, lo firma (mediante le librerie Chilkat) e restituisce la stringa firmata…

Denis.novatronica · 23 Ottobre 2020, 7:05am

Avrei preferito non farlo
é tornato, proprio lui:
“Internal Server Error”

Ahhh, quindi quando dicono “Firma digitale sí” intendono che tutti gli xml interni alla richiesta vanno firmati digitalmente e non la “busta”(o richiesta) in sé.
Grazie per l’illuminazione !

Ho confrontato gli xsd del DAS e dei Contatori energia e sebbene non abbiamo il “dichiarante”, abbiamo la lista degli xml firmati serializzati come array di byte all’interno di un XmlDTO, il quale é interno ad una xmlList.
Mentre sul DAS avete tanti blocchetti data nel corpo del messaggio qui li hanno insertiti all’interno di un tag lista.
L’equivalente del metodo process é il metodo accessPoint.

Questo avrebbe anche senso dal punto di vista dell’API e spiegherebbe perché il metodo TEST non richieda la firma (proprio perché é sprovvisto del tag xmlList, la quale raccoglie gli XML firmati).

A te il serviceId=welcomeTest con il codice di sopra(adattato al modello del DAS) senza firme digitali funziona ?

Ho un ipotesi da verificare: non abbiamo ancora l’autorizzazione ad operare sui contatori.
Perché il certificato é valido, mi permette di accedere all’HTTP e al wsdl in rete, ma appena provo ad usarlo per operare con il WebService mi solleva l’errore interno e credo sia perché al certificato manca qualcosa che il server da per scontato di trovare ma non trova.
Mi da quest’impressione

meltigel · 23 Ottobre 2020, 7:13am

Sulla parte di comunicazione API non ti posso aiutare, in quanto io sono andato direttamente sul Web Service. In pratica devi accedere al PUDM con Spid o CNS del cliente, nominare un gestore fisico, richiedere le autorizzazioni per l’azienda (nel tuo caso gestione contatori elettrici e gestione certificati), e poi delegare il gestore precedentemente creato alla gestione di tali certificati per conto dell’azienda. Finalmente si apre una schermata che ti consente di creare i certificati (di prova e ufficiali) per la comunicazione. Questo tramite il Web Service, per le API penso che non serva tutto questo giro. Hai dato una lettura ai documenti presenti sul sito? Ci sono varie sezioni, e mi pare di aver visto quella per i contatori.

WelcomeTest non lo ho mai usato, perchè sono andato direttamente in test con l’ambiente di prova…

Giovanni_De_Sisto · 28 Ottobre 2020, 3:55pm

Ciao a tutti,
mi collego al thread: anche io riscontro il medesimo errore, internal server error, che prescinde dallo strumento di invio (chiamata dritta con curl, soap to ui piuttosto che direttamente da codice java con stub client autogenerato con apache cfx).

Ho un forte presentimento che in questi giorni l’applicazione di test delle dogane non sia disponibile.

Provo ad aprire una issue al supporto tecnico. se ho news, vi chiederei la cortesia di postarle qua (avrò la stessa premura nei vostri confronti non appena riceverò una risposta).
Cordialmente
Giovanni

Denis.novatronica · 29 Ottobre 2020, 8:14am

Ciao Giovanni,
Anche tu stai cercando di inviare i dati sui contatori di Energia Elettrica ?

Il problema sembrerebbe legato al fatto che con il PUDM abbiamo generato un certificato senza l’ autorizzazione per la gestione dei contatori.
A quanto pare abbiamo solo attivato la “gestione certificati”.
Sembrerebbe che dovremo effettuare delle manovre particolari per attivare la voce che ci interessa (in quanto “nascosta”, non presente in quel super elenco).
Non sono sicurissimo di questa parte ma nel dubbio rifarei il certificato.
Perché se il WebService non funzionasse non ci risponderebbe all’HTTP e alla richiesta del WSDL …

Questo spiegherebbe il perché inviando sia il metodo TEST che una richiesta firmata digitalmente il WebService ci risponda con un errore.
Avrebbe semplicemente potuto dire “Questo certificato non é autorizzato”,
(se fosse “solo” questo andrebbe piú che bene, a patto di trovare la strada giusta per ottenere un certificato autorizzato.)
Abbiamo contattato telefonicamente Sogei e lei ci ha detto di chiamare le Dogane, mentre loro, in base all’operatore incontrato, ci hanno detto di dover prima sapere bene a cosa ci dobbiamo iscrivere
per poter gestire quello che vogliamo gestire e di sentire la Dogana locale, oppure di contattare Sogei…

Purtroppo la persona del cliente che seguiva questa questione ha dei problemi con il Covid e doveva attrezzare meglio la nuova postazione (da casa), quindi per il momento siamo fermi e in attesa di nuovi eventi.

Un Super Grazie a Giuseppe per l’aiuto, senza il quale non avrei mai capito che la firma va applicata al payload e non alla richesta in sé e quindi per aver rimosso delle variabili dall’equazione.

Giovanni_De_Sisto · 29 Ottobre 2020, 10:28am

Ciao Denis,
concordo con te che l’utenza associata al certificato debba essere correttamente configurata (nel mio caso ho verificato di persona l’associazione utenza->società->servizi e deleghe, ciononostante, mi trovo nella tua stessa situazione).

Se procedi con il rinnovo del certificato e ottieni un esito differente rispetto all’internal error, ti chiederei la cortesia di postare l’aggiornamento.

In merito alla tua asserzione " Perché se il WebService non funzionasse non ci risponderebbe all’HTTP e alla richiesta del WSDL …" non mi trovi d’accordo:
l’end point è pubblicato quindi fornisce senza problemi il wsdl. Detto questo, se l’esecuzione interna di uno qualsiasi dei suoi metodi va in eccezione e l’eccezione non è gestita, allora può benissimo eseguire il throw del quale stiamo discutendo.

Ho letto anche in merito alla tua richiesta di assistenza: nel mentre mi sono attivato anche io inoltrando la richiesta su du canali

via help desk dogane: hanno preso in carico il ticket ma per il momento nessuna risposta
tramite un’associazione di categoria (AssoSoftware) alla quale siamo iscritti come azienda. Assosw ha un canale di comunicazione diretto

Appena ho un riscontro te lo comunico.
A presto,
Giovanni

meltigel · 30 Ottobre 2020, 9:08am

Io posso postare la mia esperienza sul discorso DAS (ma credo che a Sogei non siano stupidi da diversificare le varie gestioni, il funzionamento dovrebbe essere simile). Oltre a “Gestione Certificati”, bisogna richiedere l’autorizzazione per il servizio da utilizzare (DAS Elettronico, Contatori, Otello, Tabacchi, ce ne sono diversi). Questa richiesta deve essere fatta A NOME DELL’AZIENDA CLIENTE, quindi se la vostra azienda gestisce, ad esempio, 100 clienti, questa richiesta deve farla ogni cliente singolo. Poi, ci sono due strade:

L’azienda di sviluppo fa una richiesta alle Dogane per la gestione degli invii, in questo caso ogni azienda delegherà la software house che si occuperà dell’invio per conto loro.
Ciascun cliente gestisce le cose in maniera autonoma. In questo caso, l’azienda in questione deve necessariamente delegare un soggetto fisico che si occuperà degli invii (può essere un dipendente, il titolare, chiunque). In questo caso, si inserisce un gestore e poi l’azienda stessa DELEGA per MANDATO tale gestore.
Il funzionamento di base è che per qualsiasi problema le Dogane fanno riferimento a questo soggetto fisico (firma elettronica, invii sbagliati, e quant’altro).

Accedendo al PUDM mediante SPID o CNS, nella sezione “Mio Profilo” si apre una sezione dove si possono fare tutte queste cose.

Per quanto riguarda l’assistenza, io ho utilizzato qualche volta il numero verde delle Dogane (800-257428), e selezionando il tasto in base alla necessità. Dopo un’attesa più o meno lunga, si parla con un operatore della Dogana, che nel 99% dei casi segnerà la richiesta ed aprirà un ticket direttamente a Sogei, i quali a loro volta risponderanno A MEZZO MAIL (ho provato più volte a richiedere un confronto telefonico, ma niente)… Però mi hanno dato assistenza, risolvendo il problema o indicando cosa non andava.

In ultimo, per la comunicazione con il WebService, personalmente non ho mai usato SOAP UI. Ho scritto direttamente il codice C#. Quando si invia un messaggio (ad esempio TEST), il sistema risponde con un oggetto composto da 4 campi:
-IUT(un codice numerico utile per il recupero esito e che identifica univocamente la richiesta)
-Data Registrazione
-Esito (composto a sua volta da 2 campi, tipoEsito e MessaggioRisposta) (contiene il codice e il messaggio di risposta all’invio)
-Data (è un campo di tipo Byte, che contiene dei dati).
Analizzando in debug questi campi (sempre se si riesce ad arrivare a questo punto, se non ci sono errori prima), si capisce cosa si sbaglia. Qui il sistema capisce se l’utente non è autorizzato, se i certificati non sono validi, se la firma è corrotta e quant’altro. Se vi esce come codiceEsito “20”, significa che è stato acquisito a sistema, ed è già un grandissimo passo avanti.
Poi, tramite lo IUT, si fa un recupero esito e si vede se ci sono errori di altro tipo (molto spesso i campi sbagliati o non coerenti).

Giovanni_De_Sisto · 11 Novembre 2020, 4:36pm

Ti aggiorno.
Utilizza il seguente url e la seguente struttura per il messaggio di test.
Cordialmente,
Giovanni

URL di test
https://s2stest.adm.gov.it/TaraturaStrumentiWeb/services/TaraturaStrumenti

xml TEST