Från och med den 20:e juni 2018 kommer vi att släppa stödet för flertalet kategorier av osäker nätverkstrafik för Adobe Sign. Detta krävs för att uppfylla specifika krav för PCI-överensstämmelse.

Vanliga frågor och svar

Vilken typ av nätverkstrafik påverkas av de nya krypteringsreglerna?

All trafik:

INKOMMANDE

Inkommande trafik åsyftar anslutningar som görs till våra servrar från en kund. Vi kommer att sluta stödja okrypterade anslutningar till våra API:er, dvs begäranden som använder”http:”och inte ”https:”.

När vi har gjort den här ändringen kommer kund- och partnerprogram inte att kunna skapa okrypterade anslutningar. Felbeteendet kommer att vara applikationsspecifikt.

Felmeddelanden:

Felet kommer att vara specifikt för applikationen, men kan rapporteras som ett nätverksanslutningsfel.

För att korrigera detta måste kunderna ändra sina applikationer till att specificera webbadresser med ”https:” Deras kunder måste också ha stöd för TLSv1.2. (Från och med den 9:e april är det den enda versionen av SSL/TLS som våra servrar accepterar.)

 

UTGÅENDE

Utgående trafik åsyftar anslutningar som görs från våra servrar tillbaka till kundspecificerade servrar. Det finns två kategorier:

• Uppladdningsåteranrop för dokumentuppladdningar (beskrivs här för våra REST API:er, men gäller även för tidigare SOAP API:er)

• Statusåteranrop för att meddela kunden om en avtalsstatusändring (beskrivs här för våra REST API:er, men gäller även för tidigare SOAP API:er)

 

För båda kategorierna av återanrop kommer vi att sluta stödja:

a. Okrypterade anslutningar (webbadresser med”http:”och inte ”https:”)

b. Anslutningar till servrar som inte har stöd för TLSv1.2 (med andra ord, det kommer inte längre att finnas stöd för TLSv1.0 och TLSv1.1)

c. Anslutningar till servrar som har ogiltiga certifikat. Detta inkluderar certifikat som är självsignerade eller har upphört att gälla, liksom fallet där en webbadress använder i en IP-adress i stället för ett värdnamn.

Felmeddelanden:

• Uppladdningsåteranrop: Uppladdningen returnerar ett API-fel. 

• Statusåteranrop:

För att korrigera detta:

• I Adobe Sign-applikationer för partner/kund, måste de specificerade webbadreserna för återanrop använda ”https:” och inte”http:”. Webbadresser måste också använda ett värdnamn och inte en IP-adress.

• Servrarna som dessa webbadresser refererar till måste ha stöd för TLSv1.2 och ha giltiga certifikat.


Hur vet jag om min anslutning till Adobe Sign är säker?

Vi genererar rapporter för att identifiera kunder vars befintliga inkommande eller utgående trafik är osäker. Dessa kunder meddelas direkt.

Kunder som vill testa att deras server är kompatibel kan använda olika kostnadsfria eller kommersiella verktyg, inklusive Qualys SSLLabs Server Test, för att säkerställa att deras server har stöd för TLSv1.2 och har ett giltigt certifikat.


Har Adobe publicerat en lista över metoder som stöds?

Här är tabellen som visar alla problemfall:

  • Fall som kommer att blockeras den 20:e Juni (i fetstil)
  • Fall som varit blockerade sedan april (i kursiv stil)
  • Fall som vi kommer att blockera senare i år, under det tredje kvartalet (allt annat)

Kategori

Typ av begäran

Okrypterad

TLS 1.0

TLS 1.1

Felaktigt certifikat

Inkommande API-begäranden

Alla begäranden

Blockerad den 20:e juni

Blockerad i april 2018

Blockerad i april 2018

Ej tillämpligt

Utgående API-begäranden

Återanrop för dokumentuppladdning

Blockerad den 20:e juni

Kommer att blockeras under det tredje kvartalet 2018

Kommer att blockeras under det tredje kvartalet 2018

Kommer att blockeras under det tredje kvartalet 2018

Återanrop

Blockerad den 20:e juni

Blockerad den 20:e juni

Blockerad den 20:e juni

Blockerad den 20:e juni


Finns det något annat man bör känna till om ändringarna av krypteringsstandarderna?

Statusåteranrop

För statusåteranrop måste kundens server, förutom att ha stöd för TLS 1.2, även ha stöd för någon av chiffer-sviterna nedan:

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

Denna produkt är licensierad enligt en Creative Commons Erkännande-Ickekommersiell-Dela Lika 3.0 Unported-licens  Twitter™- och Facebook-inlägg omfattas inte av villkoren i Creative Commons-licensen.

Juridiska meddelanden   |   Onlinesekretesspolicy