It appears that some subset of our requests to Microsoft Health's SDK is failing due to an SSL certificate being expired -- I've not yet been able to reproduce this in a web browser but our code is seeing this a lot since yesterday.
java.security.cert.CertificateExpiredException: NotAfter: Tue Dec 19 12:06:55 PST 2017
Eric
Related
I have an ASP.NET application hosted on IIS version 10.0 on Windows Server 2019 (Amazon EC2).
In this application i turned on the SSL. So, my client makes a GET request to the server and if the user has any Digital Certificate installed on the machine the browser prompt a certificate select window.
When the user chooses a certificate, the request goes to the backend where we validate the certificate. The problem is in some cases there is no response from the server, it refuses the request, the request appear as (failed) in chrome dev tools and our code dont event get to log the error. In this cases we already analised the clients certificates and there is nothing wrong with them.
What could be happening?
My telegram Bot doesn't receive updates anymore, Because of the last api update Which only works with tls 1.2 .
I tried with wireshark listening to check , I found that the outgoing requests are sent over tls1.2 successfully But the INCOMING ONES (updates,commands sent to my bot) fail due to HANDSHAKE FAILURE.
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
Knowing that i tried :
Enabling Tls 1.2 using Internet Options
Added client and Server Keys to SChanel entry in registry
(DisabledByDefault = 0 ; Enabled = 1)
Installed This Update kb3140245
Installed all the important updates on my windows server 2012
What should i do to solve this issue ?
Thanks for your time.
Note: This is an edited repost of my original answer, as it was deleted for being low-quality.
The issue is that in the TLS1.2 set of cipher suites, the Telegram API only accepts a limited set. Of those only TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) are supported on Windows 2012. A secure channel for SSL / TLS could not be created on create new TelegramBotClient
However Microsoft has disabled their implementations of those ciphers on Windows 2012 already in 2014 as part of a remote code execution patch: MS14-066: Vulnerability in SChannel could allow remote code execution: November 11, 2014
They are considered unsafe ciphers by among others Qualys SSL Labs and NARTAC.
Note that the Telegram API supports many other, more secure ciphers even TLS 1.3, but none of those are supported by any version of Windows 2012. TLS 1.3 is not supported by any Windows version at the time of writing.
In summary, this explains why the problem occurs. The bad news is that there is no good solution on Windows Server 2012. The oldest Windows Server version that supports Telegram bots currently is Windows Server 2016. I'm moving my bot to a Ubuntu 19.10 server.
How can I check on which TLS version our BizTalk 2016 server is running
I want to know if TLS1.2 is not enabled how can I enable the same on BizTalk 2016 server.
As BizTalk 2016 is on .Net 4.6 this tries to use TLS 1.2 first but falls back to TLS 1.1 & TLS 1.0 unless they are disabled.
MS16-065: Description of the TLS/SSL protocol information disclosure vulnerability (CVE-2016-0149): May 10, 2016
Note The .NET Framework 4.6 and later versions use TLS 1.2, TLS 1.1, and TLS 1.0 as the protocol defaults. This is discussed in the Microsoft Security Advisory 2960358 topic on the Microsoft TechNet website.
If you want to make BizTalk use TLS 1.2 exclusively you need to make sure you have either Feature Pack 2 or Feature Pack 3 (I would recommend the latest always), or if not installing feature packs, install CU 5 for BizTalk 2016. You also need to ensure that any system BizTalk connects to, including the BizTalk database server support TLS 1.2
Note there is a prerequisite:
SQL Server 2012 Native Client version 11 should be installed on all BizTalk Server systems before you apply this update. If the SQL Native Client is not installed before you apply cumulative update, the installation may not complete.
Both of those articles then link you to Support for TLS 1.2 protocol in BizTalk Server and also links leading to MS16-065: Description of the TLS/SSL protocol information disclosure vulnerability (CVE-2016-0149): May 10, 2016
I am trying to use SSL and certificates with a web service (IIS 7, Windows 2008, .NET framework 3.5 SP1). I followed the basic instructions (http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/) and was able to get the site running soon. However, I can only connect to it from a client if the client has the web server's certificate in its Trusted Root Certification Authorities/Certificates store. If I don't add the certificate on the client site, I get the error "Could not establish trust relationship for the SSL/TLS secure channel with authority" on trying to connect to the service from client.
That's the correct behavior if you're just using self-signed test certificates. In a public/production environment, your server's certificate would be issued by a common CA like GoDaddy or VeriSign, which you have to pay to obtain.
Most (client) machines already have a large list of updated CA in their trusted root such as GoDaddy, and so a server certificate signed by them for your site will validate as a valid certificate on most* machines (without you needing to provide your cert as a trusted root).
*Most, meaning that there are browsers & operating systems which may be missing (or need updates) on common certificate authorities in their trusted root store.
Where did you get this certificate? If it's not a child of one of the certificates in the root authority already I sure hope you didn't pay money for it. If you're generating them yourself this isn't surprising because nobody trusts your CA server.
I have just Installed Intermediate Certificates supplied by Thawtes, and installed their SSL certificate for a test site sat on our network behind a load of firewalls.
the dns lookup is an internal one only.
I have run a test validation service provided by Thawte locally and it responds as successful.
Yet trying to visit the site over https:// says that the organization's certificate has been revoked.
If I disable the Online Certificate Status Protocol in firefox I can view my site, but this is obviously not an option.
Has anyone else come across this problem?
Is it due to me being completely internal and the SSL provider cannot see my site?
Need help understanding what is going wrong.
This is the output from the checker:
test.elife.co.uk is successfully secured by an SSL certificate. The following certificates are correctly installed:
------Certificate 1------
--Issued To--
Organization: test.elife.co.uk
Organizational Unit: Domain Validated
Organizational Unit 2: Thawte SSL123 certificate
Organizational Unit 3: Go to https://www.thawte.com/repository/index.html
Common Name: test.elife.co.uk
--Issued By-- Organization: Thawte,, Inc.
Organizational Unit: Domain Validated SSL
Common Name: Thawte DV SSL CA
Country: US
Valid from Thu Sep 23 01:00:00 BST 2010 to Sat Sep 24 00:59:59 BST 2011
Serial Number (hex): a6e84e4a3e7ed5b61d26c2667384cec
-------------------------
------Certificate 2------
--Issued To-- Organization: Thawte,, Inc.
Organizational Unit: Domain Validated SSL
Common Name: Thawte DV SSL CA
Country: US
--Issued By--
Organization: thawte,, Inc.
Organizational Unit: (c) 2006 thawte,, Inc. - For authorized use only
Organizational Unit 2: Certification Services Division
Common Name: thawte Primary Root CA
Country: US
Valid from Thu Feb 18 00:00:00 GMT 2010 to Mon Feb 17 23:59:59 GMT 2020
Serial Number (hex): 7610128a17b682bb3a1f9d1a9a35c092
-------------------------
------Certificate 3------
--Issued To--
Organization: thawte,, Inc.
Organizational Unit: (c) 2006 thawte,, Inc. - For authorized use only
Organizational Unit 2: Certification Services Division
Common Name: thawte Primary Root CA
Country: US
--Issued By--
Organization: Thawte Consulting cc
Organizational Unit: Certification Services Division
Common Name: Thawte Premium Server CA
Locale: Cape Town, Western Cape
Country: ZA
Valid from Fri Nov 17 00:00:00 GMT 2006 to Wed Dec 30 23:59:59 GMT 2020
Serial Number (hex): 3365500879ad73e230b9e01d0d7fac91
-------------------------
Thanks in advance.
The message says it quite clearly: the certificate (one of certificates in the chain) has been revoked. And this revocation status is reported by OCSP service which is being contacted unless you disable OCSP check. This means that the certificate can't be trusted anymore and if you use it (or it's child certificate) to certify your public site, your users will get the same error. You need to contact Thawte support for further assistance.
After days of trying to fix the revoked certificate problem the answer turned out to be simple. Our IIS SSL certificate expired and the new one worked for about a week then claimed to be revoked. After making sure there were no other certificates in any certificate store for the same site we had to go into IIS manager then to sites then BINDINGS and for port 446/ssl there is a spot to select certificate. Guessing when we replaced to old one for some reason the link in the binding was lost and so it default probably to the servers own self generated certificate instead. Fixed in Bindings and then restarted IIS and the revoked certificate message went away. (hope this helps someone someday because we were down for days and never came across this specific fix )