Často kladené dotazy ohledně odchozích nezabezpečených přenosů

Veškeré přenosy:

PŘÍCHOZÍ

Příchozí přenosy jsou připojení uskutečňovaná z klienta do našich serverů. Ukončíme podporu nešifrovaných připojení k našim rozhraním API – tzn. požadavků, které používají protokol http a nikoliv https.

Po provedení této změny se zákaznickým a partnerským aplikacím nebudou dařit pokusy o navázání nešifrovaného připojení. Chybové chování bude záviset na konkrétní aplikaci.

Chybové zprávy:

Chyba bude specifická pro danou aplikaci, bude ji však možné nahlásit jako chybu síťového připojení.

Aby ji bylo možné opravit, zákazníci budou muset změnit aplikace tak, aby uváděly adresy URL s protokolem „https“. Jejich klienti také musí podporovat TLSv1.2. (Od 9. dubna je to jediná verze protokolu SSL/TLS, kterou naše servery akceptují.)

ODCHOZÍ

Odchozí přenosy jsou připojení uskutečňovaná z našich serverů zpět na servery zadané zákazníkem. Existují dvě kategorie:

• Zpětná volání při odesílání pro odesílání dokumentů (popsána zde pro naše rozhraní REST API, platí však i pro starší rozhraní SOAP API)

• Zpětná volání týkající se stavu, která zákazníka upozorňují na změnu stavu dohody (popsána zde pro naše rozhraní REST API, platí však i pro starší rozhraní SOAP API)

U obou kategorií zpětných volání ukončíme podporu:

a. Nešifrovaných připojení (pomocí adres URL s protokolem http, nikoliv https)

b. Připojení k serverům, které nepodporují TLSv1.2 (jinými slovy již nebudou podporovány protokoly TLSv1.0 a TLSv1.1)

c. Připojení k serverům, které nemají platné certifikáty. To zahrnuje certifikáty s vlastním podpisem nebo ukončenou dobou platnosti a rovněž případy, kdy adresa URL používá IP adresu, a nikoliv název hostitele.

Chybové zprávy:

• Zpětné volání při odesílání: odesílání by mělo vrátit chybu rozhraní API. 

• Zpětné volání týkající se stavu:

Postup opravy:

• V partnerských/zákaznických aplikacích Sign musí adresy URL zadané pro volání používat protokol https, a nikolivhttp.  Adresy URL musí rovněž používat název hostitele namísto IP adresy.

• Servery, na které tyto adresy URL odkazují, musí podporovat TLSv1.2 a mít platné certifikáty.

Generujeme zprávy identifikující zákazníky, jejichž stávající příchozí nebo odchozí přenosy jsou nezabezpečené. Tito zákazníci obdrží upozornění.

Zákazníci, kteří chtějí otestovat soulad serveru s tímto požadavkem, mohou použít řadu bezplatných i komerčních nástrojů, např. Qualys SSLLabs Server Test, a ujistit se, zda jejich server akceptuje TLv1.2 a má platný certifikát.

Níže je tabulka uvádějící všechny problémové případy:

• Případy, které budou zablokovány 20. června (tučně)
• Případy, které byly zablokovány v dubnu (kurzívou)
• Případy, které budou zablokovány ve 3. čtvrtletí tohoto roku (vše ostatní)

Zpětná volání týkající se stavu

V případě zpětných volání týkajících se stavu musí zákaznické servery kromě protokolu TLS 1.2 podporovat i jednu z šifrovacích sad níže:

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384