Onlangs een Windows 2016 Standard Server geïmplementeerd, met Active Directory en Exchange 2016.
We hebben SSL 1.0, 2.0 en 3.0 uitgeschakeld voor zowel Server als Client, en hebben TLS 1.0 en TLS 1.1 uitgeschakeld.
We krijgen herhaaldelijk de volgende vermelding in ons systeemlogboek. Wat veroorzaakt dit en hoe kan ik het oplossen.
Antwoord 1, autoriteit 100%
Eigenlijk moesten we TLS 1.2 inschakelen voor .NET 4.x. Het wijzigen van dit register werkte voor mij en zorgde ervoor dat het gebeurtenislogboek niet meer volliep met de Schannel-fout.
Meer informatie over het antwoord vindt u hier
Samenvatting gekoppelde info
TLS 1.2 inschakelen op systeemniveau (SCHANNEL):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
(equivalente sleutels zijn waarschijnlijk ook beschikbaar voor andere TLS-versies)
Vertel .NET Framework om de systeem-TLS-versies te gebruiken:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
Dit is misschien niet wenselijk voor edge-gevallen waar .NET Framework 4.x-toepassingen andere protocollen moeten hebben in- en uitgeschakeld dan het besturingssysteem.
Antwoord 2
Nadat we geen wijzigingen aan een productieserver hadden aangebracht, kregen we deze foutmelding. Na verschillende dingen geprobeerd te hebben en te denken dat er misschien DNS-problemen waren, loste het herstarten van IIS het probleem op (alleen herstarten van de site loste het probleem niet op). Het zal waarschijnlijk niet voor iedereen werken, maar als we dat eerst hadden geprobeerd, zou het veel tijd hebben bespaard.
Antwoord 3
In mijn geval was de Windows 2016-server waarop dit gebeurde, gehard voor naleving van de beveiliging. Als gevolg hiervan waren alleen specifieke coderingssuites toegestaan. Dit veroorzaakte een incompatibiliteit bij het maken van HTTPS-verbindingen met zeer veilige eindpunten (zoals Apple Push Notifications API aka APNS)
Om het probleem op te lossen, heb ik IIS Cryptogedownload en op de Cipher Suites geklikt knop aan de linkerkant om de lijst met ingeschakelde/uitgeschakelde coderingssuites weer te geven, en klik vervolgens op de knop “Best Practices” en startte de server opnieuw op. Probleem opgelost.
Antwoord 4
Ik heb dit hier gevonden: https://port135 .com/schannel-the-internal-error-state-is-10013-solved/
“Corrigeer bestandsrechten
Corrigeer de machtigingen in de map c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys:
Iedereen toegang: speciaal is van toepassing op ‘Alleen deze map’
Toegang tot netwerkservice: Lezen & Uitvoeren Van toepassing op ‘Deze map, submappen en bestanden’
Beheerderstoegang: volledig beheer is van toepassing op ‘Deze map, submap en bestanden’
Systeemtoegang: volledige controle Van toepassing op ‘Deze map, submap en bestanden’
IUSR-toegang: volledig beheer is van toepassing op ‘Deze map, submap en bestanden’
De interne foutstatus is 10013
Na deze wijzigingen start u de server opnieuw op. De 10013-fouten zouden moeten verdwijnen.”