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 )
Related
i heard about Ev #SSL certificate more security for website and generated and installed free #SSL #Certificate but its not showing Name in Green Lock, anyone can help me ?
Currently, no one is providing EV SSL certificate at free of cost in the market. So the certificate which you have installed may be standard or basic ssl certificate.
Second thing is that, EV SSL certificate doesn't display name in the green lock but it displays your business / organization / company name in the browser next to green padlock. If you still have confusion regarding to understand between standard ssl and ev ssl certificate, then you should read this resource https://www.tech-wonders.com/2018/09/why-ev-ssl-is-better-compared-to-standard-ssl.html where you will find in detailed information about EV SSL & how it differs from the standard ssl.
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
During initial configuration of the Puppet agent, the agent obtains a security certificate signed by an authority recognized by the master -- most often the master itself -- with which it will subsequently identify itself to the master. Does this certificate ever expire or require an update?
Yes, all certificates signed by the Puppet CA have an expiration date, including agents' certificates, the master's certificate, and the CA's own self-signed certificate if in fact it is using such. The expiration timestamp is set by adding a fixed offset (specified by the configuration setting ca_ttl) to the date & time at which the cert is signed. The default ttl is five years, which is long enough to cover the full service life of all machines in many organizations.
More problematic than an agent's certificate expiring is the CA cert expiring. If you let that happen without configuring a new CA cert then master and nodes will thereafter reject each others' certs, forcing you to manually configure new certs for all of them.
I have asp.net site on my local machine.
IIS configuration:
binding: https binding with self-signed certificate,
ssl settings: Require SSL and Require client certificates
I have installed next certificates on my machine:
CA certificate (call it 'CA Center') in Trusted Root Certification Authorities store.
Client certificate issued by 'CA Center' in Personal store
I go to site and accept server certificate. But next i get error:
HTTP Error 403.7 - Forbidden. The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
That means browser (IE) doesn't send applicable client certificates to server.
What's wrong? Should I configure something else?
I had exactly this problem, and it took me an age to figure out the cause. Turned out it was because my computer was part of a domain, and there was some sort of group policy for that domain was restricting the trusted root certificates that IIS would be willing to accept. I don't know exactly what the setting was or how to alter it, but I found I could work around it by choosing to install my certificate into the enterprise physical store using the certutil command:
certutil -addstore -v -enterprise root CertificateAuthority.cer
It sounds like the browser never prompted you to select a client certificate to send which means something is incorrect with the SSL Handshake. Try testing this with OpenSSL.
Additionally, a very common problem is having too many certificates in the Trusted Root CA folder. When the server sends the list of CAs, there is a limit to how large the list can be so if it exceeds the limit, it will truncate the remaining CA certificates. Make sure the Trusted Root CA folder doesn't have too many certificates. One way to check this is temporarily modifying the SCHANNEL in the registry editor to not send the CA List, and then re-try.
Start > Run > 'regedit' > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL >
right-click > New > DWORD > 'SendTrustedIssuerList' > Value:0
Re-install the certificates and check their effective dates. From Microsoft Support:
Download the root server certificate in a browser on the server
computer. Run the Iisca.exe command line utility that is located in
the Inetsrv directory.
Check the effective date on the client certificate and make sure that
the date and time has arrived.
Check the expiration date and make sure that the certificate has not
expired. Contact your certificate authority to see if your
certificate has expired.
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.