Using https://www.ssllabs.com it tells me my cert is revoked, firefox also says my cert is revoked
But using https://www.sslshopper.com it says my cert is fine
and I'm able to access it on Chrome
I've tried contacting GoDaddy because I believe the revocation information (CRL/OCSP) is provided by them but they directed me elsewhere
I'm not sure what other situations can cause this problem without having to rekey the cert and try again
Related
I am receiving an exception on ADFS while integrating private.xyz.com. The exception says.
Microsoft.IdentityServer.Service.SecurityTokenService.RevocationValidationException: MSIS3015: The signing certificate of the claims provider trust 'https://private.xyz.com/sp' identified by thumbprint '****************************' is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted.
at Microsoft.IdentityServer.Service.Tokens.MSISX509SecurityToken.MatchesKeyIdentifierClause(SecurityKeyIdentifierClause keyIdentifierClause)
at System.IdentityModel.Tokens.SecurityToken.ResolveKeyIdentifierClause(SecurityKeyIdentifierClause keyIdentifierClause)
at
The signing certificate is configured in the relying party trust
Get-AdfsRelyingPartyTrust "private" | fl name,RequestSigningCertificate
The thumbprint which I am getting for the certificate is same what I am getting in the error message. And the certificate is also not expired.
What all do I need to configure so I can resolve this?
If the certificate has not been revoked or is still current, it is usually because ADFS can't locate the certificate revocation list on the Internet. You can turn this off via PS.
Also, it could be that the intermediate certificates aren't loaded into the certificate store or that the certificate itself is not trusted.
You could manually add it to Trusted Certificates.
Is there a reason why Facebook doesn't allow LetsEncrypt signed certificates in their "app development" section?
I keep getting this error:
(For the untrained eye, this is me trying to setup a webhook for new messages notifications)
Blurred out the host, but it's a valid host and using chrome or firefox on Linux and Windows doesn't give any errors.
SSLLabs also says the site is perfectly valid.
Running curl https://... on my own host, sure enough I get the same error,
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
So my question is, why have Facebook (that openly supports LetsEncrypt) decided to use default curl CA bundle to verify the callback-url of an app? If that doesn't allow LetsEncrypt?
It appears to be counterproductive to me.
Is there a way around this?
SSLLabs also says the site is perfectly valid.
It shows a warning in orange, that the certificate chain is incomplete.
Your server should present all necessary intermediate certificates as well, in addition to the certificate issued for your domain. (Which was simply forgotten here by mistake.)
I am currently struggling with an issue which I am now led to believe is being caused by IIS.
I am currently testing a self signed PKI setup with a Root CA (MyNewCA), two signed Client Certificates (certificate1, certificate2) and a Revocation list (revocationlist.crl) that is also signed by the CA.
I have added certificate1 to the revocation list and published it to a http port 80 site that exists on our network. I have then created a fake site (testsite) that is secured via a TLS certificate.
From a client machine, I have run the CertUtil commands on both certificate1 and certificate2 and these commands correctly access the http crl site, and recognise that certificate1 is revoked, and certificate2 is a legitimate non revoked certificate.
However, when I connect to the testsite via a client browser, and supply the invalid certificate - IIS still serves me the page instead of giving me a 403.13 error.
I have done a ton of reading, and it seems that at times there are CRL caching issues, however the first revocation list that I published had certificate1's serial number in it, and hence even a cached version will contain that revoked cert.
I have changed the CertCheckMode in RegEdit on the IIS server to the value 4 in an attempt to force IIS to fetch the latest crl on EVERY request, but even that setting is still allowing the revoked certificate to be served to the client.
The CRL itself has;
Effective date of 19th January 2016
Next update of 20th January 2017
I can provide the certutil output if it is useful, or any other log data that would help in pinpointing the problem.
I ran Fiddler on my client machine and verified that the crl was fetched from the Http site.
If anyone can provide any insight into this issue I would greatly appreciate it.
Thanks,
It is expected behavior. IIS do not prevent access to SSL sites even if there are revocation issues with the SSL cert. It is up to client what to do with the information it receives from the server. It is up to client to perform (or to not perform) revocation checking and to make decision about further steps.
In addition, make sure if client's cache has the most recent CRL.
I'm not clear about the authorization of certificate: a website has been associated with a certificate, say https://test.mysite.com. Do I have to install the certificate on my computer before access this url?
Another question is: every certificate is issued by a CA. If I have trusted a CA before by "installing" a cerficiate, will I trust the all the following certificates issued by the same CA?
Thanks!
It depends on the library or browser you are using to access to the URL but, if the certificate is issued by a trusted CA (one that your library or browser already trusts), the web site's certificate does not need to be installed before accessing the site.
If the CA is not trusted, there are two options. One is to trust the certificate. Browsing to the page will usually open a dialog where the user can choose to trust the certificate, for example. The second is to add the CA to the list of trusted CAs. On Windows, this is done by adding the CA's certificate to the "Trusted Root Authorities" certificate store. The latter case means any other certificate issued by the CA will also be trusted.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.