I have read all the white papers on the subject, successfully signed certified and time stamped my pdf document, but confusion arises when I want to do revocation.
When I don't implement crl or ocsp in my signature properties/revocation I get that ocsp revocation check was done online.
If I implement crl, I get this :
If I implement ocsp, or ocsp and crl together, I get this:
My question would be: ocsp in my case obviously has a priority, that should be down to my CA, in this case Start Com class 1, am i right? and is this a good way to implement both(because as it looks i can only see ocsp even dough I implemented both). and why is it, in both cases, check revocation button grayed out? what am I missing?
Related
I created the certificate authority server using Node.js and some cryptographic library supporting RSA sign, verification and generating X.509. When I added the certificate revocation feature with Online Certificate Status Protocol(OCSP), I thought of why I have to send a request and receive a response with OCSP because only what I want to know is not OCSP Request/Response object but just certificate status(Good or revoked.)
Does it make sense requesting not OCSP response object(.PEM or something else) but the certificate status value like HTTP status code(200: OK, 400: NOT FOUND)?
OCSP (Online Certificate Status Protocol) is a standard protocol to get the current status of a certificate ruled by RFC6960
The protocol defines the interchanged messages, including content, encoding, content-type and HTTP response codes.
If you want to build a general-purpose PKI it does not make sense to define your own protocol because no current client will use it (browsers, mobile devices, software tools, etc.), but expect you to have a standard OCSP service.
But if you are going to build your own client tools for an internal PKI it may be useful to have a very simple status query service (e.g 200 GOOD, 401 REVOKED, 404 UNKNOWN). But in that case do not call it OCSP
The reason OCSP responds with an object signed by the CA is so that relying parties know that the object and hence the certificate status is authentic.
If your new status service receives a query of "What is the status of certificate with serial number 123456789" and returns a simple HTTP response, the client will not be able to authenticate that response; making it very simple to carry out a substitution attack and place a 200 GOOD response when in fact the certificate's private key has been compromised and a 401 REVOKED should be sent.
You cannot fix that by responding over HTTPS as that will result in perpetual recursive status checking.
You could possibly use HTTPS if the status server's certificate is issued by a CA that doesn't use your protocol, instead using alternatives such as OCSP or a CRL distribution point. But that just makes the whole solution more complex instead of simplifying the status checking problem.
Quick question,
Could there be any explanation for the fact that the IdP sends a certificate that is old and doesn't match the certificate that the SP expects, but SSO still works?
Could it be that the public keys somewhere else still match?
I have seen certificates where the public key doesn't change but the expiry date, serial number etc do change. This isn't common though.
The more likely scenarios are:
(i) the IdP is using the certificate expected by the SP,
(ii) the SP is using the embedded certificate,
(iii) the SP isn't verifying the signature.
If you take a look at the received SAML response it normally includes the base-64 encoded certificate embedded in the XML signature.
You can check this against the certificate you are expecting.
I learnt something about ocsp recently.
I check ocsp stapling of site by command like:
$openssl s_client -connect www.stackoverflow.com:443 -status -servername www.stackoverflow.com
I found my own site and stackoverflow and some other small sites have ocsp settings. They have OCSP Response Data field in command response.
But when I check some big sites like google.com, github.com, facebook.com, they don't have such a field. And I get OCSP response: no response sent.
So why they don't use it?
To protect your users, as a web server, you must use OCSP must staple. But even in such a situation, you need to consider that OCSP responses that are given are often valid for multiple days, so an attacker can get an OCSP valid status for a server certificate before the certificate was revoked, and insert it as an OCSP stapled status during its MitM attack to a web client (of course, the attacker must be the same that hacked the certificate and for which the certificate has been revoked). So, a browser, that would not support OCSP stapling and that would require OCSP, would be protected. A browser supporting OCSP stapling would not be. This is one of the reasons why OCSP stapling is not the ultimate choice. there are some cases where it is a less secure way to avoid security flaws, and some other cases where it is useless. Even if it is not a bad attempt to get more trust on the Internet, of course.
So, some big companies like Google offer other means to protect their customers and users using their browsers: they want to offer a more secure experience to their users, comparing to other browsers, because their goal is to get more users. For this purpose, Google Chrome implements the proprietary CRLSets mechanism.
The same companies and others also want to promote other ways for people to get (back) trust on the Internet. For instance, some companies follow Google to promote the Certificate Transparency mechanism. So, this would be a bad idea, politically speaking, to implement OCSP stapling on their site and working for another trust mechanism for the Internet.
The best paper I've read about certificate revocation and the means to protect your users is here: https://arstechnica.com/information-technology/2017/07/https-certificate-revocation-is-broken-and-its-time-for-some-new-tools/
My answer is: probably because saving more bytes in response.
Alexandres's answer (specially bolded text) may be correct for google.com, but not for facebook.
OCSP stapled response would be present in every TLS connection and this takes many bytes. Why would happen if no OCSP staple exists in response?! client sends a OCSP verify request to orginal server and caches response for several days. For popular sites like google and facebook, users see pages several times a day, and normally OCSP response is cached at client and no OCSP request is required (e.g. only 2% of clients need actual OCSP request).
So for this popular sites, removing OCSP stapling (and saving a hundred bytes for 98% of requests) is a better choice than making a site faster for 2% of requests.
We are trying to setup a custom SAML integration with the Cisco WebEx. However WebEx SP keeps complaining about the "Invalid digital signature" after the SAML Response is sent to WebEx.
We have already inspected the SAML Response, Signing Cert, and the Fiddler trace of the SAML transaction. Nothing seems out of ordinary. We have done this for several other services and have not run into any issues.
Is there a good tool that can help us debug as to why WebEx is thinking the Digital Signature is invalid?
There are a few reasons why a digital signature might be seen as invalid.
Altered Document:
Ensure that the document you are signing is not in any way altered after it is signed. Even the addition of a whitespace character will invalidate the signature.
Character Encoding:
If your document contains unicode charaters, ensure that you have the correct encoding specified. Most SAML documents are expected to be encoded in UTF8 like so: <?xml version="1.0" encoding="utf-8"?>
Wrong Element Signed: A SAML document containing an Assertion is usually expected to have a signature on the Assertion itself, and not necessarily on the entire document.
Incorrect Certificate: Ensure that the certificate you've given the authority is a match with the key you are signing. Some implementations will have you include the certificate in the document, where others might require you to predefine the certificate. If the one in your document does not match the one they have on file, the signature will not be seen as valid. Are you signing with an SSL certificate? Did you recently update it?
Ultimately you should test the document yourself. Many SAML libraries will have a mechanism for validating a signature. Does yours appear valid to your library? Failing that, you can use something like xmlsec1 to manually validate your document with your certificate. This is likely what your library is using to encrypt, and likely what the authority is using to validate.
Using XMLSec:
Given a certificate called cert.pem and a SAML Response XML document called doc.xml you would validate it like so:
$ xmlsec1 --verify --pubkey-cert-pem cert.pem --id-attr:ID Response doc.xml
OK
SignedInfo References (ok/all): 1/1
You may need to alter the --id-attr value to match the ID attribute of your document. You are looking for output similar to the above to inform you that your document's signature is valid with the provided certificate.
Check that you're signing the Assertion element, not the toplevel Response element.
I am using iText to apply digital signatures in PDF. The digitally signed PDF is showing message like "the validity of the document certification is unknown. The author could not be verified.At least one signature has problems." at the top.
When I add the certificate to my trust identities which is used to create signed PDF, then the generated signed PDF shows "Signed and all signatures are valid".
Is it possible to fix this by without adding certificate to trusted identities?
Thanks in advance.
There are two reasons for the message to be displayed.
First, it's that you used self-signed certificate or other certificate, whose certificate chain doesn't end with the root certificate, trusted by validating application.
Second is when the signature parameters are not set right and Reader doesn't know that it needs to look for certificates in Windows certificate store. I don't know how to specify what I mean in iText - in our SecureBlackbox there's a property for this.
Please read https://itextpdf.com/book/digitalsignatures
Section 3.4 is named "How to get a green check mark."
The short version: if you want a PDF that shows a green check mark without having to install a root certificate manually, you need at least a private key that is stored on a physical device such as a Hardware Security Module, a USB token or a smart card.
Do you have such a key? Did you ask your CA for CDS or AATL certificate?
Re: Is it possible to fix this by without adding certificate to trusted identities?
Answer: no, unless you switch to a digital signature cert that was granted by a Certificate Authority trusted by Adobe.
This is an on-going issue with Adobe since Adobe Reader doesn't trust the CA's in the operating system. -- Instead, Adobe has their own list.
So either:
You get a personal cert from one of the companies on the Adobe list.
You publish your organization's root certificate on your website and provide instructions to recipients on how to tell Adobe to trust you. (Your organization can have just one member if you wish.) See below for more on this.
You tell your recipients how to click on the Adobe signature toolbar to inspect the details of the signing cert (and ignore the scary default warnings from Adobe).
In the wet-signature world, there are cases where you simply sign something, and other cases where you need to provide a copy of your government issued identity document. Unfortunately, in the current digital signature world, it's as if every signature needs to be accompanied by a copy of your driver's license. And that is simply not reality.
A common and successful answer is to publish your organization's root cert for all of the organization's signers. See Apple and Wells Fargo examples.
You can publish your root cert on an SSL-protected page with a cert from a trusted CA. That will enable a business partner to feel secure about trusting that your org's root cert is really from your org.