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.
Related
when some players enter our game, they meet this error in all browsers
We have changed the certificate recently. So I check one player's certificate on our game page,
It is the lastest certificate. So what may cause this problem? Should we do something after change the certificate?
EDIT1
Did CDN cache the certificate? After we refresh the CDN, some player can connect to the game immediately.
EDIT2
We found the player's browser has such an option "block unsafe certificate", when the option is enabled, he can't connect to the server and he can connect to server when the option is disabled. We export the intermediate certificate and send it to the player for import. After that, the player can play the game with the option selected.
EDIT3
Finally we found the intermediate certificate is right on the nginx side,but on the server side, the ca is missing. After add it, the websocket could work. And When I asked same question on another forum v2ex,I found a good way to test if the certificate chain is complete. you can visit the site and change the domain and port with your site.
https://cert.catbox.io/api/v1/queryChain?domain=s41001-ad-tanwan.zlgl.17tanwan.com&port=8085
If your server is correct, you will find the server side certificate and the intermediate certificate.If you can't find the intermediate certicate, you need to check your server config.
Your server https://s41001-ad-tanwan.zlgl.17tanwan.com/ provides only the last certificate in the chain, the actual certificate of the server.
This certificate is signed by the intermediate certificate from "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" that is valid since 2020-07-16.
If the clients have not updated their browsers/operating systems for some time, they don't have this intermediate certificate, and they report this as an invalid certification authority.
Put the intermediate certificate to the certificate file, and it should fix the problem, since the intermediate certificate is signed by the DigiCert root certificate, that is in the game since 2006. Everyone has it.
You run nginx, right? The ssl_certificate instruction in nginx accepts files with certificate chains. This file should have the server certificate first, then the intermediate certificate.
I would like to use google certificate transparency API to check the malicious SSL certificates(if any) of my domain. I am able to get all the certificates but how do i check whether the certificate is legitimate or not.
I had found this repository(https://github.com/ProtonMail/ct-monitor) but this simply searches certificates and stores it . What is the use of storing these certificates unless we validate the certificates first.
Can any one suggest me how do i get to know the malicious SSL certificates using this google certificate transparency api.
Certificate Transparency logs are, as explained on the CT site:
simple network services that maintain cryptographically assured,
publicly auditable, append-only records of certificates. Anyone can
submit certificates to a log, although certificate authorities will
likely be the foremost submitters.
The logging of the certificates in this fashion allows for interested parties (e.g. domain owners) to monitor these logs for malicious/erroneous
entries.
But a certificate being logged in a CT log doesn't mean it isn't a bad certificate. As explained on the CT site:
Certificate Transparency relies on existing mitigation mechanisms to
address harmful certificates and CAs--for example, certificate
revocation--the shortened detection time will speed up the overall
mitigation process when harmful certificates or CAs are discovered.
So CT API won't help you in working out whether a certificate is malicious - you need to check using other methods such as checking of certificate revocation lists (CRLs) or by using the Online Certificate Status Protocol (OCSP). See this related question on how to check certs. There are sites that allow for checking of certificates e.g. revocationcheck.com. Modern browsers seem to be converging on the use of compressed lists of CRLs - Mozilla's now using CRLite, whilst Chrome uses CRLSets.
The CT API allows you verify that a certificate has been logged in the CT logs which means that domain owners can monitor them and promptly insert any malicious/erroneous certificates into the relevant CRLs so they won't be used any longer.
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
Good day!
In my asp.net web application I need to check incoming digital signatures of files. I do it by calling:
SignedCms.CheckSignature(false) or SignerInfo.CheckSignature(false) (C#).
And I want to ensure, that signers’ certificates during such calls are checked for revocation correctly, ensure that system settings are correct and to clear this process for myself.
Incoming signers’ certificates maybe of large amount of CA’s. So, the signer’s certificate may or may not include references to CA’s OCSP service or CA’s CRL service.
I want the system to check revocation in such way:
IF certificate has reference to CA’s OCSP web service then the system makes the request to CA,
ELSE
IF certificate has a reference to CA’s online CRL service the system downloads CRL and uses it
ELSE
System uses the local CRL.
Could you, please, answer my questions:
how (where) can I find the system settings which describe needed behavior? (Is this behavior changable or fixed?)
If the certificate has reference to CRL web service of CA, must I download and install the CA’s CRL by script periodically, or I can rely on the system downloads and uses them automatically when it needs CRL for checking?
Thank you.
The procedure is described in RFC 5280 and is very complicated. In brief, you do the following:
For certificate in question, check it's signature, validity period and key usage
Check the certificate against CRL.
Check the certificate against OCSP
For each certificate encountered during CRL and/or OCSP checking, perform steps 1-3 (this in turn can involve multiple CRL and OCSP checks).
I am not mentioning policy checks, which are very complicated, here.
It took me about a month to implement certificate validator for our SecureBlackbox library (but we have everything on our own, from CRL and OCSP clients to management of those CRLs). If you want to perform certificate checking using OS means, you should be looking for existing function that does the job for you.
You can find some useful information on getting internals of the CRL, more specifically on the CRL caching crl-caching-in-windows-and-little-bit
There are two approaches which i am thinking here, where, windows cryptoAPI will take care of handling the revocation by itself automatically including caching. But the issue here is that cryptoAPI will look for the CA server only when the current CRL in the cache expires. So there is the difficulty of maintaining the freshness of the CRL. But if your CA's CRL publishing frequency is on a daily basis, you may get away with this approach of using CertVerifyRevocation, function call from windows with appropriate configuration for some applications.
The second approach is to download and install the CRL from the CA server and use CertFindCertificateInCRL for validation. Your CRL down-loader application can be configured to update the CRL at a predefined time interval. This will work, if the CA publishes only Base CRL, as you get the entire revoked certificate list when you download your CRL every time. I donot know the answer, to what happens if the CA publishes the Delta CRL and the Base CRL at less frequent intervals.
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.