"Il certificato X.509 CN = servicebus.windows.net" Coda bus servizio di Azure

Question

Utilizziamo Azure Service Bus e Azure Web App che riempiono la coda. Sono nello stesso gruppo di risorse. Usiamo WindowsAzure.ServiceBus v2.6.5.

Otteniamo questo errore molto raramente:

Il certificato X.509 CN = servicebus.windows.net non è nella gente negozio di fiducia. Il certificato X.509 CN = costruzione della catena servicebus.windows.net non riuscita. Il certificato che è stato utilizzato ha una catena di fiducia che non può essere verificata. Sostituire il certificato o modificare il CertificateValidationMode. Non è stato possibile creare una catena di certificati per un'autorità di radice attendibile.

Domanda: È presente un errore interno su Azure? Se non lo è, cosa possiamo fare per non ottenere questo errore?

Answer 1

Credo che ci debba essere un certificato mancante.

Da questo overflow dello stack messaggio https://stackoverflow.com/a/24224550/4735373 ecco un link che può aiutare: https://corp.sts.microsoft.com/Onboard/ADFSOnboard.htm#Corp-STS-Certificates

Answer 2

sono riuscito a trovare il nostro ulteriori informazioni su questo problema. Prima di tutto, ciò che deve essere stabilito è che si tratta di un problema di puro client, questo è il motivo per cui non ci sono ID di tracciamento. Il cliente rifiuta di completare l'handshake TLS con il bus di servizio.

Questo è un problema noto, questo è un problema noto con il modo in cui Microsoft gestisce i certificati e il modo in cui vengono utilizzati sui trasporti non HTTP (S). Gli errori si verificano quando l'endpoint che ospita i certificati intermedi per Microsoft non è disponibile o è lento o non può essere raggiunto dal client per nessuna ragione. Stiamo esaminando una soluzione alternativa per inserire nell'attesa handshake TLS per per il trasporto SBMP e AMQP in modo simile a come viene eseguito da HTTP.SYS, in modo che questa richiesta aggiuntiva non sia necessaria.

La soluzione immediata disposizione è consentire ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https questo costringerà tutto il traffico di utilizzare un tunnel WebSockets che è protetta da una prima TLS/HTTPS handshake, e che porta handshake il certificato intermedio richiesto. L'handshake WebSockets fa sì che imponga un po 'di latenza aggiuntiva quando viene stabilita la connessione, ma il sarà altrimenti comparabile con la normale modalità di comunicazione. Il protocollo di messaggistica utilizzato attraverso quel tunnel sarà ancora AMQP o NetMessaging, quindi non dovresti essere preoccupato di ottenere le caratteristiche HTTP quando scegli questa opzione.

Questa è la risposta di Microsoft. Lo applicherò e se non dovessi affrontare alcun problema in un periodo di tempo, accetterò questa come risposta. Chi affronta questo problema, può provare anche questo.

Edit:

ConnectivityMode.Https è solo in autobus servizio available 3. Devo usare ServiceBus 2 a causa della issue su Signalr. Pertanto non ho potuto applicare questa soluzione.