none
Errore Schannel irreversibile definito dal protocollo TLS: 42 nella chiamata di un servizio web RRS feed

  • Domanda

  • Ciao a tutti,

    ho un problema con dei servizi WCF che girano sul mio server (sistema operativo Windows Server 2012 R2). I servizi sono stati sviluppati per dialogare con il sistema di interscambio dell'agenzia delle entrate (per gestire la fatturazione elettronica).

    Lo SdI richiama i miei servizi per inviare notifiche e fatture da ricevere; l'autenticazione viene fatta tramite certificato e tutto funziona regolarmente. C'è solo un piccolo problema: sporadicamente succede che il tentativo di chiamata al mio servizio non va a buon fine, nel log di IIS viene registrato un errore 500 e, contestualmente, nel visualizzatore degli eventi di sistema di Windows viene registrato il messaggio di errore Schannel 36887 (Ricevuto avviso di errore irreversibile dall'endpoint remoto. Codice dell'avviso di errore irreversibile definito dal protocollo TLS: 42).

    Ad esempio, succede che su 100 chiamate al mio servizio, 99 sono ok ed 1 va in errore e non riesco a capire quale possa essere il motivo di tale comportamento.

    In questa discussione è descritta una problematica molto simile alla mia: https://blogs.technet.microsoft.com/keithab/2016/11/11/transport-layer-security-tls-handshake-failing-schannel-error-36888/

    Vi allego i log di IIS e il dettaglio dell'errore registrato:

    #Software: Microsoft Internet Information Services 8.5
    #Version: 1.0
    #Date: 2018-12-24 20:15:57
    #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
    2018-12-24 20:15:57 [MIOIP] POST /OlisoftWSRicezione/Service.svc - 443 - 217.175.52.231 IBM+WebServices/1.0 - 500 0 64 250
    #Software: Microsoft Internet Information Services 8.5
    #Version: 1.0
    #Date: 2018-12-24 20:46:01
    #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
    2018-12-24 20:46:01 [MIOIP]POST /OlisoftWSRicezione/Service.svc - 443 - 217.175.52.231 IBM+WebServices/1.0 - 200 0 0 1375


    Nome registro: System
    Origine:       Schannel
    Data:          24/12/2018 21:15:57
    ID evento:     36887
    Categoria attivitĂ :Nessuna
    Livello:       Errore
    Parole chiave: 
    Utente:        SYSTEM
    Computer:      svrtest
    Descrizione:
    Ricevuto avviso di errore irreversibile dall'endpoint remoto. Codice dell'avviso di errore irreversibile definito dal protocollo TLS: 42.
    XML evento:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" />
        <EventID>36887</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2018-12-24T20:15:57.608316400Z" />
        <EventRecordID>25732</EventRecordID>
        <Correlation />
        <Execution ProcessID="604" ThreadID="7028" />
        <Channel>System</Channel>
        <Computer>svrtest</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="AlertDesc">42</Data>
      </EventData>
    </Event>

    Da cosa può dipendere? Avete qualche suggerimento?


    venerdì 28 dicembre 2018 11:36

Risposte

Tutte le risposte

  • Ciao Luca, l'alert 42 indica "BAD_CERTIFICATE". Mi viene il sospetto che l'errore possa essere dovuto a delle specifiche sessioni durante le quali il certificato non viene accettato.

    Il certificato che utilizzi è sicuramente valido altrimenti non funzionerebbe ma potrebbe non essere riconosciuto da qualche destinatario. Proverei a sentire chi ti ha fornito il certificato. Hai notato l'errore avviene su specifiche connessioni (es. sempre lo stesso fornitore o sempre quando esegui l'invio di una fattura a...)?

    Saluti
    Nino


    www.testerlab.it


    venerdì 28 dicembre 2018 13:35
    Moderatore
  • Ciao Nino, si infatti avevo visto che si tratta di un errore "BAD_CERTIFICATE", la cosa insolita però è che è sempre lo SdI a chiamare i miei servizi e sempre con lo stesso IP (come puoi vedere dal log) solo che di norma la chiamata va a buon fine, mentre in sporadiche occasioni va in errore; immagino che il tipo di chiamata che fanno verso il servizio sia sempre la stessa.

    Ho provato a contattare più volte l'agenzia delle entrate per avere un chiarimento ma è praticamente impossibile parlare con qualche tecnico e rispondono sempre in maniera generica.

    Non riesco proprio a capire.

    venerdì 28 dicembre 2018 13:48
  • Prova a contattare la CA ed eventualmente, come indicato nell'articolo che hai menzionato, attiva un trace dei pacchetti per cercare di identificare eventuali anomalie rispetto alle chiamate che vanno a buon fine.

    Saluti
    Nino


    www.testerlab.it

    venerdì 28 dicembre 2018 13:58
    Moderatore
  • il certificato l'hai richiesto allo SDIcoop o è un tuo certificato ?

    https://www.fatturapa.gov.it/export/fatturazione/it/FAQ_accreditamento_canale.htm


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    venerdì 28 dicembre 2018 15:59
    Moderatore
  • il certificato l'hai richiesto allo SDIcoop o è un tuo certificato ?

    https://www.fatturapa.gov.it/export/fatturazione/it/FAQ_accreditamento_canale.htm


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    Si si, richiesto all'SDICoop; ho generato le csr e le ho inviate, loro mi hanno risposto con i certificati client e server; l'autenticazione funziona, infatti ho superato tutti i test e mi sono accreditato, poi però monitorando le chiamate al servizio su IIS ho notato questo strano errore che si verifica saltuariamente.

    Non so se possa dipendere dalla Cipher Suite di Windows Server, ho provato a modificarle dai criteri di gruppo locali ma non so quali sono le più indicate, dalle prove che ho fatto l'errore si continua a presentare.

    Sniffando il traffico ho visto che ci sono delle chiamate da parte dello SdI che a volte utilizzano il protocollo TLS 1.0 ed a volte il TLS 1.2, può essere?

    Nello specifico ho estratto queste Cipher Suite...

    Cipher Suite estratta dall'handshake "Client Hello" TLS 1.0
    TLS_RSA_WITH_AES_256_CBC_SHA(53)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA(57)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA(56)
    TLS_RSA_WITH_AES_128_CBC_SHA(47)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA(51)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA(50)
    TLS_RSA_WITH_3DES_EDE_CBC_SHA(10)
    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA(22)
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA(19)
    TLS_RSA_WITH_NULL_SHA(2)
    TLS_RSA_WITH_NULL_MD5(1)
    TLS_RSA_WITH_DES_CBC_SHA(9)
    TLS_DHE_RSA_WITH_DES_CBC_SHA(21)
    TLS_DHE_DSS_WITH_DES_CBC_SHA(18)
    65278
    TLS_EMPTY_RENEGOTIATION_INFO_SCSV(255)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(49162)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(49172)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(49157)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(49167)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(49161)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(49171)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(49156)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(49166)
    TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA(49160)
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA(49170)
    TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA(49155)
    TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA(49165)
    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA(49159)
    TLS_ECDHE_RSA_WITH_RC4_128_SHA(49169)
    TLS_RSA_WITH_RC4_128_SHA(5)
    TLS_ECDH_ECDSA_WITH_RC4_128_SHA(49154)
    TLS_ECDH_RSA_WITH_RC4_128_SHA(49164)
    TLS_RSA_WITH_RC4_128_MD5(4)
    65279
    TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA(102)
    TLS_RSA_EXPORT_WITH_RC4_40_MD5(3)
    TLS_RSA_EXPORT_WITH_DES40_CBC_SHA(8)
    TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA(20)
    TLS_RSA_WITH_NULL_SHA(2)
    TLS_RSA_WITH_NULL_MD5(1)
    TLS_RSA_WITH_DES_CBC_SHA(9)
    TLS_DHE_RSA_WITH_DES_CBC_SHA(21)
    TLS_DHE_DSS_WITH_DES_CBC_SHA(18)
    65278
    TLS_EMPTY_RENEGOTIATION_INFO_SCSV(255)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(49162)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(49172)
    TLS_RSA_WITH_AES_256_CBC_SHA(53)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(49157)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(49167)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA(57)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA(56)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(49161)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(49171)
    TLS_RSA_WITH_AES_128_CBC_SHA(47)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(49156)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(49166)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA(51)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA(50)
    TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA(49160)
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA(49170)
    TLS_RSA_WITH_3DES_EDE_CBC_SHA(10)
    TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA(49155)
    TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA(49165)
    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA(22)
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA(19)
    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA(49159)
    TLS_ECDHE_RSA_WITH_RC4_128_SHA(49169)
    TLS_RSA_WITH_RC4_128_SHA(5)
    TLS_ECDH_ECDSA_WITH_RC4_128_SHA(49154)
    TLS_ECDH_RSA_WITH_RC4_128_SHA(49164)
    TLS_RSA_WITH_RC4_128_MD5(4)
    65279
    TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA(102)
    TLS_RSA_EXPORT_WITH_RC4_40_MD5(3)
    TLS_RSA_EXPORT_WITH_DES40_CBC_SHA(8)
    TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA(20)
    TLS_RSA_WITH_NULL_SHA(2)
    TLS_RSA_WITH_NULL_MD5(1)
    TLS_RSA_WITH_DES_CBC_SHA(9)
    TLS_DHE_RSA_WITH_DES_CBC_SHA(21)
    TLS_DHE_DSS_WITH_DES_CBC_SHA(18)
    65278
    TLS_EMPTY_RENEGOTIATION_INFO_SCSV(255)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(49162)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(49172)
    TLS_RSA_WITH_AES_256_CBC_SHA(53)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(49157)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(49167)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA(57)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA(56)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(49161)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(49171)
    TLS_RSA_WITH_AES_128_CBC_SHA(47)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(49156)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(49166)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA(51)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA(50)
    TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA(49160)
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA(49170)
    TLS_RSA_WITH_3DES_EDE_CBC_SHA(10)
    TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA(49155)
    TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA(49165)
    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA(22)
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA(19)
    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA(49159)
    TLS_ECDHE_RSA_WITH_RC4_128_SHA(49169)
    TLS_RSA_WITH_RC4_128_SHA(5)
    TLS_ECDH_ECDSA_WITH_RC4_128_SHA(49154)
    TLS_ECDH_RSA_WITH_RC4_128_SHA(49164)
    TLS_RSA_WITH_RC4_128_MD5(4)
    65279
    TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA(102)
    TLS_RSA_EXPORT_WITH_RC4_40_MD5(3)
    TLS_RSA_EXPORT_WITH_DES40_CBC_SHA(8)
    TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA(20)
    TLS_RSA_WITH_NULL_SHA(2)
    TLS_RSA_WITH_NULL_MD5(1)
    TLS_RSA_WITH_DES_CBC_SHA(9)
    TLS_DHE_RSA_WITH_DES_CBC_SHA(21)
    TLS_DHE_DSS_WITH_DES_CBC_SHA(18)
    65278
    TLS_EMPTY_RENEGOTIATION_INFO_SCSV(255)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(49162)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(49172)
    TLS_RSA_WITH_AES_256_CBC_SHA(53)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(49157)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(49167)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA(57)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA(56)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(49161)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(49171)
    TLS_RSA_WITH_AES_128_CBC_SHA(47)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(49156)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(49166)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA(51)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA(50)
    TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA(49160)
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA(49170)
    TLS_RSA_WITH_3DES_EDE_CBC_SHA(10)
    TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA(49155)
    TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA(49165)
    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA(22)
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA(19)
    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA(49159)
    TLS_ECDHE_RSA_WITH_RC4_128_SHA(49169)
    TLS_RSA_WITH_RC4_128_SHA(5)
    TLS_ECDH_ECDSA_WITH_RC4_128_SHA(49154)
    TLS_ECDH_RSA_WITH_RC4_128_SHA(49164)
    TLS_RSA_WITH_RC4_128_MD5(4)
    65279
    TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA(102)
    TLS_RSA_EXPORT_WITH_RC4_40_MD5(3)
    TLS_RSA_EXPORT_WITH_DES40_CBC_SHA(8)
    TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA(20)
    TLS_RSA_WITH_NULL_SHA(2)
    TLS_RSA_WITH_NULL_MD5(1)
    TLS_RSA_WITH_DES_CBC_SHA(9)
    TLS_DHE_RSA_WITH_DES_CBC_SHA(21)
    TLS_DHE_DSS_WITH_DES_CBC_SHA(18)
    65278
    TLS_EMPTY_RENEGOTIATION_INFO_SCSV(255)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(49162)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(49172)
    TLS_RSA_WITH_AES_256_CBC_SHA(53)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(49157)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(49167)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA(57)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA(56)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(49161)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(49171)
    TLS_RSA_WITH_AES_128_CBC_SHA(47)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(49156)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(49166)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA(51)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA(50)
    TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA(49160)
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA(49170)
    TLS_RSA_WITH_3DES_EDE_CBC_SHA(10)
    TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA(49155)
    TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA(49165)
    TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA(22)
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA(19)
    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA(49159)
    TLS_ECDHE_RSA_WITH_RC4_128_SHA(49169)
    TLS_RSA_WITH_RC4_128_SHA(5)
    TLS_ECDH_ECDSA_WITH_RC4_128_SHA(49154)
    TLS_ECDH_RSA_WITH_RC4_128_SHA(49164)
    TLS_RSA_WITH_RC4_128_MD5(4)
    65279
    TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA(102)
    TLS_RSA_EXPORT_WITH_RC4_40_MD5(3)
    TLS_RSA_EXPORT_WITH_DES40_CBC_SHA(8)
    TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA(20)

    Cipher Suite estratta dall'handshake "Client Hello" TLS 1.2
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(49200)
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(49196)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(49192)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(49188)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(49172)
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(49162)
    TLS_DH_DSS_WITH_AES_256_GCM_SHA384(165)
    TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(163)
    TLS_DH_RSA_WITH_AES_256_GCM_SHA384(161)
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(159)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(107)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(106)
    TLS_DH_RSA_WITH_AES_256_CBC_SHA256(105)
    TLS_DH_DSS_WITH_AES_256_CBC_SHA256(104)
    TLS_DHE_RSA_WITH_AES_256_CBC_SHA(57)
    TLS_DHE_DSS_WITH_AES_256_CBC_SHA(56)
    TLS_DH_RSA_WITH_AES_256_CBC_SHA(55)
    TLS_DH_DSS_WITH_AES_256_CBC_SHA(54)
    TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA(136)
    TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA(135)
    TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA(134)
    TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA(133)
    TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(49202)
    TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(49198)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(49194)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(49190)
    TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(49167)
    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(49157)
    TLS_RSA_WITH_AES_256_GCM_SHA384(157)
    TLS_RSA_WITH_AES_256_CBC_SHA256(61)
    TLS_RSA_WITH_AES_256_CBC_SHA(53)
    TLS_RSA_WITH_CAMELLIA_256_CBC_SHA(132)
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(49199)
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(49195)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(49191)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(49187)
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(49171)
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(49161)
    TLS_DH_DSS_WITH_AES_128_GCM_SHA256(164)
    TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(162)
    TLS_DH_RSA_WITH_AES_128_GCM_SHA256(160)
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(158)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(103)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(64)
    TLS_DH_RSA_WITH_AES_128_CBC_SHA256(63)
    TLS_DH_DSS_WITH_AES_128_CBC_SHA256(62)
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA(51)
    TLS_DHE_DSS_WITH_AES_128_CBC_SHA(50)
    TLS_DH_RSA_WITH_AES_128_CBC_SHA(49)
    TLS_DH_DSS_WITH_AES_128_CBC_SHA(48)
    TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA(69)
    TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA(68)
    TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA(67)
    TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA(66)
    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(49201)
    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(49197)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(49193)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(49189)
    TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(49166)
    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(49156)
    TLS_RSA_WITH_AES_128_GCM_SHA256(156)
    TLS_RSA_WITH_AES_128_CBC_SHA256(60)
    TLS_RSA_WITH_AES_128_CBC_SHA(47)
    TLS_RSA_WITH_CAMELLIA_128_CBC_SHA(65)
    TLS_EMPTY_RENEGOTIATION_INFO_SCSV(255)

    Sto ancora analizzando la cosa per capire in quale frangente si verifica l'errore; se nel frattempo avete dei suggerimenti ben vengano.



    venerdì 28 dicembre 2018 16:52
  • Sto continuando ad analizzare il traffico sul server per cercare di individuare il problema. Ho installato Microsoft Message Analyzer, in allegato trovate uno screen dell'handshake di una delle chiamate che è andata in errore. Il primo dubbio che mi viene è questo: da quello che vedo sembra che il protocollo di crittografia utilizzato è il TLS 1.0, secondo voi è corretto? O è più opportuno utilizzare il TLS 1.2? Se si, sapete indicarmi come intervenire sul server per cambiare il protocollo di crittografia predefinito?


    venerdì 4 gennaio 2019 15:06
  • se l'applicazione si basa sulla versione 4.7 del .net framework la crittografia usa automaticamente il TLS 1.2

    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    venerdì 4 gennaio 2019 15:30
    Moderatore
  • Ciao Luca, il protocollo dovrebbe essere negoziato in base alla versione di sistema operativo e framework. Di conseguenza, non credo sia possibile impostare un default. Quello che potresti poter fare è abilitare/disabilitare la versione TLS in base al seguente documento https://blogs.technet.microsoft.com/askds/2015/12/08/speaking-in-ciphers-and-other-enigmatic-tonguesupdate/. Ovviamente è d'obbligo eseguire un backup completo ed esportare le chiavi interessate per poter ritornare indietro in caso di problemi.

    Saluti
    Nino


    www.testerlab.it

    venerdì 4 gennaio 2019 15:35
    Moderatore
  • Il sistema operativo è Windows Server 2012 R2 e i servizi WCF sono basati sul framework 4.6.2

    Nel registro, sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols trovo solo SSL 2.0

    Leggerò l'articolo che hai linkato, da quello che ho capito bisogna aggiungere delle chiavi di registro...cercherò di capirci meglio.

    Oggi purtroppo, con il traffico che è aumentato sul server, questi errori sono diventati più frequenti.

    venerdì 4 gennaio 2019 17:37
  • Ho trovato anche il seguente documento che fa riferimento anche alla versione  Framework 4.6 https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

    www.testerlab.it

    sabato 5 gennaio 2019 06:45
    Moderatore
  • Il sistema operativo è Windows Server 2012 R2 e i servizi WCF sono basati sul framework 4.6.2

    Nel registro, sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols trovo solo SSL 2.0

    Leggerò l'articolo che hai linkato, da quello che ho capito bisogna aggiungere delle chiavi di registro...cercherò di capirci meglio.

    Oggi purtroppo, con il traffico che è aumentato sul server, questi errori sono diventati più frequenti.

    non conta quali versioni del framework sono installate sul server, devi rifare la tua applicazione usando la versione del framework 4.6.2 o 4.7 che utilizzano in maniera nativa la versione di crittografia più elevata.

    sono stato costretto a fare questa attività anch'io su applicazioni che ho in azure ed utilizzano paypal. paypal ha cambiato sistema di crittografia e l'utnica soluzione è quella di adeguare l'applicazione alla versione più recente del framework.

    ciao


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    sabato 5 gennaio 2019 08:17
    Moderatore

  • non conta quali versioni del framework sono installate sul server, devi rifare la tua applicazione usando la versione del framework 4.6.2 o 4.7 che utilizzano in maniera nativa la versione di crittografia più elevata.

    sono stato costretto a fare questa attività anch'io su applicazioni che ho in azure ed utilizzano paypal. paypal ha cambiato sistema di crittografia e l'utnica soluzione è quella di adeguare l'applicazione alla versione più recente del framework.

    ciao


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    No ma infatti il target framework del mio progetto dei servizi WCF è 4.6.2, difatti sul web.config ho i seguenti settaggi

     <system.web>
        <compilation strict="false" explicit="true" targetFramework="4.6.2" />
        <httpRuntime targetFramework="4.6.2"/>
      </system.web>
    però, nonostante questo, quando lo SdI richiama i miei servizi sembra che il protocollo di crittografia utilizzato sia TLS 1.0; che poi non so se può essere questa la natura del problema che avevo segnalato, però volevo fare una prova facendo in modo che il protocollo negoziato fosse TLS 1.2 e vedere se il problema si presenta ancora.





    sabato 5 gennaio 2019 10:20
  • leggi attentamente questo documento

    https://docs.microsoft.com/it-it/dotnet/framework/network-programming/tls

    e in particolare

    Per WCF con .NET Framework 4.6 - 4.6.2 e la sicurezza del trasporto TCP con credenziali del certificato

    È necessario installare le patch più recenti del sistema operativo. Vedere Aggiornamenti della sicurezza.

    Il framework WCF sceglie automaticamente il protocollo più alto disponibile fino a TLS 1.2, a meno che non si configuri in modo esplicito una versione del protocollo. Per altre informazioni, vedere la sezione precedente Per il trasporto TCP WCF con sicurezza del trasporto con credenziali del certificato.


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    lunedì 7 gennaio 2019 14:54
    Moderatore
  • Ciao, ho anch'io lo stesso problema con il Web Service RicezioneFatture.

    Le chiamate che fa il SDI sono tutte con TLS 1.0 (mi apsetterei la versione 1.2) ma solo alcune vanno in errore...

    Per caso sei riuscito a risolvere?

    Grazie

    mercoledì 9 gennaio 2019 17:15
  • Ciao Luca

    Anche noi abbiamo un canale SdICoop accreditato in invio e ricezione con dei servizi WCF (.NET 4.5) in ascolto che girano su Windows Server 2008 R2 ed IIS 7.5. I servizi esposti autenticano il client mediante un certificato a livello Transport.

    Abbiamo praticamente lo stesso problema, i log di IIS segnalano errore 500, evento che si verifica in modo totalmente casuale e negli eventi di sistema viene notificato l'errore 42 (BAD_CERTIFICATE) event id 36887.

    Per avere un dettaglio maggiore per quanto riguarda il processo di handshake TLS ho modificato il livello di logging si SCHANNEL impostando a "7" il valore attribuito al DWORD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging" nel registro di sistema, ma oltre al suddetto errore non sono riuscito ad ottenere altre info utili alla risoluzione del problema. L'unica cosa è che tutte le request usano TLS 1.0.


    Non stiamo riuscendo a venine a capo e purtroppo è quasi impossibile ricevere assistenza da parte dell'Agenzia delle Entrate su problematiche tecniche. Ho anche ipotizzato che lato SdI esistano molteplici "workers" che si occupano di smistare le fatture e le notifiche, prendendosi l'onere di contattare i servizi accreditati, e che alcuni di essi abbiano qualche problema di configurazione (mi arrampico sugli specchi?!)....

    Luca, ad oggi sei riuscito a capire la natura del problema?

    Saluti

    Pasquale

    mercoledì 9 gennaio 2019 18:39
  • Stesso identico problema. Anche io ho abilitato il log Schannel al massimo dettaglio.

    Questi sono gli eventi Schannel loggati nell'Event Viewer quando una chiamata dal SdI fallisce con status http 500

    1) EventID 36867
    Creating an SSL server credential.

    2) EventID 36868
    The SSL server credential's private key has the following properties:

       CSP name: Microsoft Enhanced Cryptographic Provider v1.0
       CSP type: 1
       Key name: {62F754D4-4BD7-42D8-8774-B13D45E06591}
       Key Type: key exchange
       Key Flags: 0x20

     The attached data contains the certificate.

    3) EventID 36880
    An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.

       Protocol: TLS 1.0
       CipherSuite: 0x2F
       Exchange strength: 2048

    4) EventID 36887
    A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 42.

    Dal log 3) sembrerebbe quindi che il problema non sta nella versione TLS, ma in qualcosa dopo.

    La verifica dei certificati nel mio caso non viene fatta a livello applicazione WCF ma direttamente da IIS 8.

    Ho notato che tra 3) e 4) quando la chiamata dal SdI va in errore passa qualche secondo.

    Quando invece la chiamata dal SdI va a buon fine al 4) c'è un record di log identico al 3).

    Ho provato a estrarre il certificato in 2) e ho verificato che combiacia con il certificato di autenticazione server che ho correttamente installato sul mio IIS 8.

    Ho anche disabilitato la client certificate revocation come spiegato qui https://blogs.msdn.microsoft.com/kaushal/2012/10/15/disable-client-certificate-revocation-crl-check-on-iis/ ma non ha risolto.

    Quello che però non mi è ancora chiaro è se il problema sia sul certificato client presentato dal SdI o sul certificato server presentato dal mio IIS 8. Dai log il problema sembrerebbe sul certificato server presentato dal mio IIS 8, e quella frase "A fatal alert was received from the remote endpoint" sembrerebbe indicare che il certificato server presentato dal mio IIS 8 non è piaciuto al SdI.
    In tal caso però la domanda è: dal momento che il certificato server installato sul mio IIS 8 è sempre lo stesso, come mai a volte piace e a volte no?

    Probabilmente, ipotesi che ho fatto, i server del SdI sono talmente carichi che non riescono a verificare sempre correttamente (con tutto il giro delle crl) i certificati di autenticazione server rilasciati da "CA Agenzia delle Entrate" e installati sulle varie macchine sparse per il paese.

    • Modificato alb84 giovedì 10 gennaio 2019 09:45
    giovedì 10 gennaio 2019 08:27
  • Io credo invece che il problema non sia sul certificato server: se fosse così il client SDI bloccherebbe a monte il processo e non partirebbe nemmeno la chiamata e quindi sui nostri log di IIS e SCHANNEL non avremmo traccia dell'errore. 

    La mia è solo un'ipotesi non ho la certezza...


    giovedì 10 gennaio 2019 10:09
  • Credo anch'io che il problema non sia legato al certificato server: in tal caso qualsiasi altra richiesta da parte dello SdI sarebbe stata rigettata, cosa non vera nel nostro caso!

    Considerando la natura totalmente casuale dell'errore, essendo che l'alert riporta il codice 42 BAD_CERTIFICATE riferito al certificato client e considerando che già siamo in quattro ad essere nella stessa situazione (anche con versioni di .net, IIS e Windows Server differenti!) a questo punto propenderei più nel considerare l'ipotesi che il problema sia legato a come lo SdI consuma i servizi da noi esposti, nel senso che potrebbero esserci più agenti client che non interagiscono tutti allo stesso modo esponendo un certificato che non riusciamo a leggere/verificare.

    Bisognerebbe capire se anche altri colleghi che hanno usato tecnologie differenti (ad esempio Java, PHP....) riscontrano problemi simili.

    giovedì 10 gennaio 2019 11:00
  • Come mai dici che l'errore 42 è riferito al certificato client?

    La descrizione dell'errore 42 è generica (da https://blogs.msdn.microsoft.com/kaushal/2012/10/05/ssltls-alert-protocol-the-alert-codes/):

    "There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified."

    e guardando i log Schannel nell'Event Viewer al record 1) vedo "Creating an SSL server credential" e al record 2) il certificato allegato è quello installato su IIS per l'autenticazione server, sono questi i motivi che mi avevano fatto pensare a un problema sul certificato server anzichè sul certificato client

    in ogni caso secondo me non è da escludere la possibilità che pur essendo un errore che si verifica saltuariamente sia un errore relativo al certificato server, ad esempio una mia ipotesi era che il server della crl sia sovraccarico e per qualche motivo i client del SdI che chiamano i nostri servizi solo a volte non riescono a verificare i nostri certificati di autenticazione server... ma ripeto è solo un'ipotesi, che comunque sarebbe avallata dal fatto che al punto 2) il certificato allegato è quello server unito al fatto che il messaggio dice "A fatal alert was received FROM THE REMOTE endpoint"
    • Modificato alb84 venerdì 11 gennaio 2019 09:20
    giovedì 10 gennaio 2019 11:30
  • Ciao Alb84

    Effettivamente l'errore BAD_CERTIFICATE è generico, potrebbe essere riferito sia al client che al server, ma se per ipotesi il problema fosse il nostro certificato server allora gli errori sarebbero una costante.

    In precedenza noi abbiamo avuto errori http 403.13 (client certificate revoked) e vista l'impossibilità di ricevere assistenza dall'AdE abbiamo provveduto a disabilitare la verifica della revoca del certificato client dal binding https e questo ci ha consentito di risolvere l'errore.

    Avendo disabilitato questo controllo suppongo (ma non ne sono sicuro al 100%) che lato server non venga fatta alcuna richiesta alla lista CRL della CA perchè la verifica sulle revoche è stata disabilitata. Ma suppongo che la stessa verifica venga comunque effettuata dal client rispetto al certificato server da noi esposto e che, a causa di problemi di accesso alla CRL (come da te ipotizzato, un sovraccarico del loro servizio LDAP), il processo di handshake si interrompa in modo inatteso ed il server ritorni errore 500.

    Se questo ragionamento dovesse essere corretto purtroppo noi ci possiamo fare poco o niente se non bombardare di telefonate il servizio di assistenza tecnica dell'AdE.... 



     
    venerdì 11 gennaio 2019 12:32
  • in alternativa alle telefonate io solitamente aprivo un modulo di assistenza:

    https://www.fatturapa.gov.it/export/fatturazione/it/assistenza.htm

    solitamente quando ero in fase di test mi rispondevano in uno o due giorni

    però adesso ne ho aperto uno proprio relativamente a questo problema tre giorni fa e non ho ancora avuto risposta

    in ogni caso, visto che siamo tutti nello stesso problema, proporrei che chiunque trovasse la soluzione o anche solo scoprisse qualcosa di nuovo di condividere qui con tutti

    venerdì 11 gennaio 2019 13:09
  • Ciao a tutti, anche io non ho trovato ancora una soluzione...però devo dire che sapere che non sono l'unico ad avere questo tipo di problema un po' mi rincuora. In questi giorni purtroppo non ho potuto seguire la cosa, spero di poter fare qualche test nei prossimi. Ad ogni modo vi riassumo le info che ho trovato...

    In questo documento dell'agenzia https://www.fatturapa.gov.it/export/fatturazione/sdi/indicazioni_operative_nuove_specifiche.pdf si dice esplicitamente che il protocollo di cifratura da utilizzare è TLS 1.2; per questo volevo capire se c'era il modo di utilizzare "obbligatoriamente" il TLS 1.2 nel momento in cui lo SdI richiama il mio servizio...purtroppo non ho ancora avuto modo di vedere se e come è possibile farlo.

    Per escludere che si trattasse di un problema di carichi/concorrenza di chiamate ho realizzato anche un piccolo client di prova per fare uno stress test, che richiama con diversi thread ed in diverse iterazioni un metodo del mio servizio, ma non ho riscontrato alcun tipo di errore.

    Suggerisco anche io che ognuno di noi apra delle segnalazioni/telefonate/mail (magari linkando anche queste discussione), in modo che l'AgE possa prendere seriamente in considerazione la cosa.


    venerdì 11 gennaio 2019 14:03
  • Ciao Luca, nel primo articolo che ti ho indicato è descritto come abilitare/disabilitare TLS 1.0/1/2.

    Saluti
    Nino


    www.testerlab.it

    sabato 12 gennaio 2019 14:09
    Moderatore
  • Ciao Luca, nel primo articolo che ti ho indicato è descritto come abilitare/disabilitare TLS 1.0/1/2.


    www.testerlab.it

    Si infatti avevo letto e, appena riesco, volevo provare quello.


    lunedì 14 gennaio 2019 08:01
  • Ciao a tutti.

    Chi di voi che lamenta questa problematica è un associato Assosoftware? Sul forum dell'associazione stiamo trattando il problema perchè a quanto pare siamo in molti a lamentare questo malfunzionamento che si ripercuote sui nostri clienti che lamentano notifiche di mancata consegna per quanto riguarda le fatture passive.

    Se siete in Assosoftware vi consiglio di entrare nel forum e seguire la cosa. In ogni caso vi terrò aggiornati su ulteriori sviluppi.

    lunedì 14 gennaio 2019 14:58
  • Aggiornamento

    Ho provato ad abilitare TLS 1.2 in questo modo:
    - Ho installato l'aggiornamento KB3140245 sul mio Windows Server 2012
    - Ho definito le relative chiavi di registro DisabledByDefault con valore 0 come descritto qui https://support.microsoft.com/it-it/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi
    - Ho riavviato la macchina

    Ora non arriva più nessuna chiamata dal SdI, e non viene più nemmeno loggata nell'access log di IIS 8.
    Guardando i log Schannel:
    - Non vedo più l'errore "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 42"
    - Non viene più negoziato TLS 1.0 con CipherSuite: 0x2F ma viene negoziato TLS 1.2 con CipherSuite: 0x3C
    - Ogni tanto vedo l'errore "A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 10. The Windows SChannel error state is 1203."

    Secondo questo sito l'errore 10.1203 sembra un errore molto generico e non previsto:
    https://serverfault.com/questions/936218/what-are-the-security-risks-of-selecting-allow-local-activation-security-check
    Anche abilitando la policy "Allow local activation security check exemptions" come descritto nel link, non vedo più l'errore 10.1203, ma le chiamate dal SdI continuano a non arrivare.
    mercoledì 16 gennaio 2019 08:54
  • Ciao a tutti. 

    Sono riuscito a dedicare un po di tempo ed ho provato a seguire il consiglio di Nino lasciando attivo solo tls 1.2. Purtroppo il problema persiste.

    Continuo ad essere convinto che l'anomalia non sia nostra ma di chi consuma i servizi da noi pubblicati oppure nella CRL su protocollo LDAP esposto dalla CA.

    Purtroppo al momento non ho altre notizie in merito.

    Saluti

    Pasquale

    mercoledì 16 gennaio 2019 09:16
  • Ho riscritto al SdI, questa volta mi hanno risposto immediatamente:

    Testo richiesta:
    Buongiorno,
    occasionalmente alcune chiamate provenienti dal SdI giungono al nostro server ma vanno in errore http 500.
    Quando cio` accade, nell'Event Viewer del mio server vedo l'errore 'A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 42', e il protocollo utilizzato e` TLS 1.0.
    Tuttavia anche le chiamate che vanno a buon fine sembrerebbero utilizzare sempre TLS 1.0.
    Non sapendo che pesci pigliare ho provato ad abilitare TLS 1.2. Se lo lascio abilitato pero` non arriva alcuna chiamata, e ogni tanto vedo un nuovo errore 'A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 10. The Windows SChannel error state is 1203'.
    So che molti altri utenti hanno lo stesso problema. Windows Server 2012 con IIS 8.0. Avete consigli o indicazioni?


    Il servizio di assistenza ha individuato una proposta di soluzione al problema.

    La soluzione proposta è la seguente:
    Gentile utente,
    Le consiglio di verificare che richiamando l'endpoint di test da browser venga sempre richiesto un certificato. In caso contrario la configurazione SSL non è ben definita e le notifiche non possono esser consegnate.

    La cosa fondamentale è sempre la verifica della configurazione che deve essere corretta.
    MOLTO IMPORTANTE: Verificare che sia implementato NON solo il TLSv1.2 ma anche il TLSv1.0 e TLS1.1 Si tratta di configurazioni di sicurezza.
    Se vuol configurare il TLSv1.2, noi possiamo suggerirle di implementare comunque anche gli altri protocolli con le cifrature più alte. In ogni caso, verifichi la configurazione SSL del proprio servizio.
    Sogei non può fornire assistenza sulla configurazione di sicurezza di terze parti.


    mercoledì 16 gennaio 2019 09:27
  • Ma dal browser la chiamata al servizio ti funziona?

    Io solitamente, per testare che sia tutto ok, importo il certificato client sul browser, a quel punto richiamo l'url del servizio e mi viene richiesto il certificato da utilizzare, una volta scelto viene visualizzata la definizione del servizio.

    Chiaramente tutto questo con la configurazione attuale, non so se abilitando il TLS 1.2 cambia qualcosa.

    Ad ogni modo, mi sembra di capire che Sogei non prende neanche minimamente in considerazione che il problema possa dipendere dal modo in cui loro fanno la chiamata.


    mercoledì 16 gennaio 2019 11:22
  • Ho anche risposto al ticket cercando di insinuare che potesse magari dipendere da loro:

    Ho provato a lasciare abilitati sia TLS 1.0 sia TLS 1.2 ma ho visto che ancora adesso alle 11:02 è arrivata una chiamata dal SdI con protocollo TLS 1.0 ed è andata in errore con "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 42".
    Immediatamente prima di tal errore nel log vedo "An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows. Protocol: TLS 1.0 CipherSuite: 0x2F Exchange strength: 2048".
    La descrizione dell'errore 42 è "There is a problem with the certificate, for example, a certificate is corrupt, or a certificate contains signatures that cannot be verified".
    Il mio dubbio è se sia un problema di certificato server o di certificato client.
    Dal log sembrerebbe un problema del certificato server installato sul mio IIS, ma in tal caso come mai a volte le chiamate funzionano e a volte no?
    Siccome l'errore dice "A fatal alert was received FROM THE REMOTE endpoint", non potrebbe essere un vostro problema di verifica del mio certificato server, che si verifica solo saltuariamente, ipotizzo ad esempio per sovraccarico delle CRL?

    Questa è stata la risposta:

    Il servizio di assistenza ha individuato una proposta di soluzione al problema.

    La soluzione proposta è la seguente:

    Gentile utente

    come da segnalazione precedente le consiglio di lasciare abilitato il TLS 1.1 (versione a noi segnalata come più stabile) in maniera esclusiva. Fermo restando che non conosciamo la sua specifica configurazione, e che non possiamo entrare nel merito della stessa, le ricordiamo di attenersi alle linee guida descritte sul sito.

    mercoledì 16 gennaio 2019 13:08

  • Gentile utente

    come da segnalazione precedente le consiglio di lasciare abilitato il TLS 1.1 (versione a noi segnalata come più stabile) in maniera esclusiva. Fermo restando che non conosciamo la sua specifica configurazione, e che non possiamo entrare nel merito della stessa, le ricordiamo di attenersi alle linee guida descritte sul sito.

    Veramente la documentazione del sito parla di TLS 1.2, adesso dicono TLS 1.1. Non se ne esce.
    mercoledì 16 gennaio 2019 13:43
  • Scusate, i log che vedevo che usavano TLS 1.2 e gli errori Schannel "The TLS protocol defined fatal error code is 10. The Windows SChannel error state is 1203" non erano relativi a chiamate SdI.

    Per ricapitolare, la mia situazione quindi ora è la seguente:
    Windows Server 2012 Standard 64 bit
    IIS 8.0
    Abilitato supporto per TLS 1.0, TLS 1.1, TLS 1.2
    Ricompilato il progetto con Framework .NET 4.7 (con targetFramework="4.7" nel web.config)

    Tutte le chiamate che arrivano dal SdI negoziano SEMPRE i seguenti parametri:
    Protocol: TLS 1.0
    CipherSuite: 0x2F (TLS_RSA_WITH_AES_128_CBC_SHA)
    Exchange strength: 2048

    Alcune delle quali vanno a buon fine, altre vanno in errore 500 sempre col solito errore "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 42" nel log Schannel.
    mercoledì 16 gennaio 2019 14:47
  • Mi accodo anche io, stesso identico problema. Windows Server 2012, applicazione .net 4.6.1

    A me in particolare l'errore 500, oltre che capitare sporadicamente, si verifica sempre se l'applicazione è al primo avvio, come se ci fosse un problema di timeout per il tempo di negoziazione del certificato…

    Altri come me o è dovuto alla lentezza del mio server?

    grazie


    Maurizio

    mercoledì 16 gennaio 2019 15:00
  • Ho trovato una discussione relativa allo stesso problema su forum.italia.it:

    https://forum.italia.it/t/canale-sdicoop-produzione-errori-403-saltuari/6921/18

    il problema si presenta anche con i server Apache.

    Un utente dice di aver risolto seguendo le indicazioni di questo articolo:

    https://boyan.io/random-500-errors-iis-client-certificates/

    Non ancora avuto modo di capire bene il motivo e pianificare un test, ma sembra un suggerimento molto interessante.



    • Proposto come risposta Daniele B 83 giovedì 17 gennaio 2019 06:09
    mercoledì 16 gennaio 2019 18:14
  • Ho provato e sembra funzionare: questa notte ho ricevuto più di 20 tra fatture e notifiche senza nessun errore 500.

    Anche se non mi è ben chiaro a cosa serva di preciso questa impostazione...

    Mi chiedo poi perchè, se è così importante, non venga richiesta o perlomeno segnalata nelle specifiche del Sistema di Interscambio.

    giovedì 17 gennaio 2019 07:45
  • Ho provato e sembra funzionare: questa notte ho ricevuto più di 20 tra fatture e notifiche senza nessun errore 500.

    Anche se non mi è ben chiaro a cosa serva di preciso questa impostazione...

    Mi chiedo poi perchè, se è così importante, non venga richiesta o perlomeno segnalata nelle specifiche del Sistema di Interscambio.

    Buono, quindi hai eseguito il comando da prompt come descritto nell'articolo? attivando il clientcertnegotiation=Enable?
    giovedì 17 gennaio 2019 07:48
  • Ho provato e sembra funzionare: questa notte ho ricevuto più di 20 tra fatture e notifiche senza nessun errore 500.

    Anche se non mi è ben chiaro a cosa serva di preciso questa impostazione...

    Mi chiedo poi perchè, se è così importante, non venga richiesta o perlomeno segnalata nelle specifiche del Sistema di Interscambio.

    Buono, quindi hai eseguito il comando da prompt come descritto nell'articolo? attivando il clientcertnegotiation=Enable?
    Si esattamente.
    giovedì 17 gennaio 2019 07:55
  • Ragazzi ho buone notizie!

    Pare che abbiano risolto il problema! Ieri pomeriggio ci siamo attivati in sede assosoftware per intercedere presso la Sogei che a quanto pare ha ammesso di avere riscontro rispetto a questa problematica che (a quanto pare) interessava solo servizi in ascolto su Windows Server - IIS.

    Da stamattina alle 1:30 non abbiamo più registrato alcun errore, le fatture arrivano che è una meraviglia.

    Datemi anche voi un riscontro in tal senso.



    giovedì 17 gennaio 2019 08:51
  • Ragazzi ho buone notizie!

    Pare che abbiano risolto il problema! Ieri pomeriggio ci siamo attivati in sede assosoftware per intercedere presso la Sogei che a quanto pare ha ammesso di avere riscontro rispetto a questa problematica che (a quanto pare) interessava solo servizi in ascolto su Windows Server - IIS.

    Da stamattina alle 1:30 non abbiamo più registrato alcun errore, le fatture arrivano che è una meraviglia.

    Datemi anche voi un riscontro in tal senso.



    Io veramente ancora riscontro il problema, ma ancora devo provare ad impostare il "clientcertnegotiation=Enable".
    giovedì 17 gennaio 2019 09:12
  • Ragazzi ho buone notizie!

    Pare che abbiano risolto il problema! Ieri pomeriggio ci siamo attivati in sede assosoftware per intercedere presso la Sogei che a quanto pare ha ammesso di avere riscontro rispetto a questa problematica che (a quanto pare) interessava solo servizi in ascolto su Windows Server - IIS.

    Da stamattina alle 1:30 non abbiamo più registrato alcun errore, le fatture arrivano che è una meraviglia.

    Datemi anche voi un riscontro in tal senso.



    Quindi adesso non so più se era un problema lato nostro o di SOGEI visto che proprio ieri sera ho seguito la guida postata da Luca Petrini e da quel momento non rilevo più errori... 

    Pazienza

    giovedì 17 gennaio 2019 09:17
  • Noi avevamo già la negoziazione del certificato client abilitata e nonostante questo il problema si verificava random.

    Di fatto non abbiamo nessuna risposta ufficiale da parte di nessuno, è solo una nostra costatazione fatta sui log dove il problema non si è più verificato.

    Adesso sporadicamente registriamo un fallimento dell'handshake (errore 40) ma la frequenza di questo errore può essere considerata trascurabile rispetto alla situazione precedente.
    • Modificato Paskos giovedì 17 gennaio 2019 12:15
    giovedì 17 gennaio 2019 11:54
  • Noi avevamo già la negoziazione del certificato client abilitata e nonostante questo il problema si verificava random.

    Di fatto non abbiamo nessuna risposta ufficiale da parte di nessuno, è solo una nostra costatazione fatta sui log dove il problema non si è più verificato.

    Adesso sporadicamente registriamo un fallimento dell'handshake (errore 40) ma la frequenza di questo errore può essere considerata trascurabile rispetto alla situazione precedente.
    Per quanto riguarda il TLS avete lasciato abilitato solo l'1.2?
    giovedì 17 gennaio 2019 13:38
  • No, abbiamo abilitato TLS 1.0, TLS 1.1 e TLS 1.2
    giovedì 17 gennaio 2019 13:56
  • Per rispondere al post di Paskos, pure a me pare che non abbiamo risolto un bel niente.
    Da ieri io sul mio server non ho toccato più niente e ancora stamattina vedo diverse chiamate dal SdI andate in errore 500.

    Attualmente ho Negotiate Client Certificate: Disabled, proverò a settare Negotiate Client Certificate: Enabled e vi farò sapere.

    • Modificato alb84 giovedì 17 gennaio 2019 14:31
    giovedì 17 gennaio 2019 14:29
  • Con Negotiate Client Certificate: Enabled vedo che viene comunque sempre utilizzato TLS 1.0, mentre la CipherSuite negoziata non è più 0x2F (TLS_RSA_WITH_AES_128_CBC_SHA) ma 0x4 (TLS_RSA_WITH_RC4_128_MD5), e per ora sembra vadano tutte a buon fine...


    giovedì 17 gennaio 2019 15:47
  • Qualcuno ha aggiornamenti? Negotiate Client Certificate Enabled è la soluzione?

    Maurizio

    lunedì 21 gennaio 2019 13:22
  • Ho effettuato la configurazione con ClientCertNegotiation=Enable e per ora non ho più riscontrato il problema.
    lunedì 21 gennaio 2019 14:19
  • Ho effettuato la configurazione con ClientCertNegotiation=Enable e per ora non ho più riscontrato il problema.
    Confermo anch'io: dal 17 Gennaio nessun errore riscontrato con la negoziazione abilitata. Tra l'altro sono anche stato contattato da un tecnico dell'assistenza (in risposta ad una mia segnalazione) il quale mi ha confermato che è un problema già noto e che a breve faranno un troubleshooting su questo e altri errori ricorrenti
    lunedì 21 gennaio 2019 14:38
  • Io ho attivato la "ClientCertNegotiation" da circa un paio d'ore, sembra stia funzionando correttamente. Ho ricevuto un centinaio di chiamate dallo SdI senza rilevare errori.

    Venerdì pomeriggio mi ha chiamato anche Sogei per avere informazioni sulla natura dell'errore, gli ho indicato questa discussione; credo che stiano vedendo il problema anche loro.


    lunedì 21 gennaio 2019 16:42
  • Ottimo...

    www.testerlab.it

    lunedì 21 gennaio 2019 16:55
    Moderatore
  • Si confermo, nessun problema dopo la modifica. La suggerisco come soluzione

    Maurizio

    lunedì 21 gennaio 2019 19:01