Met ingang van 20 juni 2018 worden verschillende categorieën onveilig netwerkverkeer niet meer ondersteund voor Adobe Sign. Dit is nodig om te voldoen aan de specifieke vereisten voor PCI-naleving.

Veelgestelde vragen

Welk type netwerkverkeer wordt beïnvloed door de nieuwe coderingsregels?

Al het verkeer:

BINNENKOMEND

Binnenkomend netwerkverkeer verwijst naar verbindingen die een client tot stand brengt met onze servers. Niet-gecodeerde verbindingen naar onze API's worden niet langer ondersteund, hiermee bedoelen we verbindingen die gebruikmaken van "http:" in plaats van "https:".

Nadat deze wijziging is doorgevoerd, mislukken pogingen van klant- en partnertoepassingen om niet-gecodeerde verbindingen tot stand te brengen. Het foutgedrag varieert per toepassing.

Foutberichten:

Fouten zijn specifiek voor een toepassing, maar er kan een probleem met de netwerkverbinding worden gerapporteerd.

Om dit probleem te verhelpen, moeten gebruikers hun toepassingen wijzigen en "https:"-URL's gebruiken. Hun clients moeten bovendien ondersteuning bieden voor TLSv1.2. (Vanaf 9 april is dat de enige versie van SSL/TLS die onze servers accepteren.)

 

UITGAAND

Uitgaand netwerkverkeer verwijst naar verbindingen van onze servers terug naar door de klant opgegeven servers. Er zijn twee categorieën:

• Uploadcallbacks voor documentuploads (hier beschreven voor onze REST-API, maar ook van toepassing op de verouderde SOAP-API)

• Statuscallbacks om de klant op de hoogte te stellen van een wijziging in de overeenkomststatus (hier beschreven voor onze REST-API, maar ook van toepassing op de verouderde SOAP-API)

 

Voor beide categorieën callbacks wordt het volgende niet langer ondersteund:

a. Niet gecodeerde verbindingen (die "http:"- in plaats van "https:"-URL's gebruiken)

b. Verbindingen naar servers die geen ondersteuning bieden voor TLSv1.2 (met andere woorden TLSv1.0 en TLSv1.1 worden niet meer ondersteund)

c. Verbindingen naar servers die ongeldige certificaten hebben. Dit omvat certificaten die automatisch zijn ondertekend of die zijn verlopen, evenals gevallen waarin een URL een IP-adres gebruikt in plaats van een hostnaam.

Foutberichten:

• Uploadcallback: de upload retourneert een API-fout 

• Statuscallbacks:

Om dit probleem te verhelpen:

• In Sign-toepassingen van partners/klanten moeten de URL's die worden opgegeven voor callbacks gebruikmaken van "https:" en niet van "http:". De URL's moeten bovendien een hostnaam gebruiken in plaats van een IP-adres.

• De servers waar deze URL's naar verwijzen, moeten TLSv1.2 ondersteunen en geldige certificaten hebben.


Hoe weet ik of mijn verbinding met Adobe Sign veilig is?

We genereren rapporten om de klanten te identificeren van wie het bestaande inkomende of uitgaande verkeer niet veilig is. Deze klanten worden rechtstreeks op de hoogte gesteld.

Klanten die willen testen of hun server compatibel is, kunnen verschillende gratis of commerciële tools gebruiken, zoals de Qualys SSLLabs Servertest, om te controleren of hun server TLSv1.2 accepteert en een geldig certificaat heeft.


Heeft Adobe een lijst met alle ondersteunde methoden gepubliceerd?

De volgende tabel bevat alle probleemgevallen:

  • Gevallen die op 20 juni zijn geblokkeerd (vet gedrukt)
  • Gevallen die in april al zijn geblokkeerd (cursief gedrukt)
  • Gevallen die in het derde kwartaal van dit jaar worden geblokkeerd (alle andere)

Categorie

Type aanvraag

Niet gecodeerd

TLS 1.0

TLS 1.1

Ongeldig certificaat

Inkomende API-verzoeken

Alle verzoeken

Geblokkeerd op 20 juni

Geblokkeerd in april 2018

Geblokkeerd in april 2018

N.v.t.

Uitgaande API-verzoeken

Document Upload Callback

Geblokkeerd op 20 juni

Wordt geblokkeerd in het derde kwartaal van 2018

Wordt geblokkeerd in het derde kwartaal van 2018

Wordt geblokkeerd in het derde kwartaal van 2018

Statuscallback

Geblokkeerd op 20 juni

Geblokkeerd op 20 juni

Geblokkeerd op 20 juni

Geblokkeerd op 20 juni


Is er nog iets wat ik moet weten over de wijzigingen inzake coderingsstandaarden?

Statuscallbacks

Voor statuscallbacks dient de server van de klant niet alleen ondersteuning te bieden voor TLS 1.2, maar ook voor een van de volgende versleutelingssuites:

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

Dit werk is gelicentieerd onder de Creative Commons Naamsvermelding/Niet-commercieel/Gelijk delen 3.0 Unported-licentie  De voorwaarden van Creative Commons zijn niet van toepassing op Twitter™- en Facebook-berichten.

Juridische kennisgevingen   |   Online privacybeleid