Here I have a question about the principle of SignedXml.CheckSignature.
As we know, if we call the function with verifySignatureOnly = false, it can verify the certificate.
[ComVisibleAttribute(false)]
public bool CheckSignature(
X509Certificate2 certificate,
bool verifySignatureOnly
)
But how can it verify?
According to my understanding, certificate should be a public key encrypted by CA private key. so CheckSignature can get the CA public key, then decrypt the certificate?
I want to know how it works. Hope some one can help.
It uses windows certificate store to build a certificate chain up to trusted root authority. When it is building the chain the method also verifies revocation status of the certificates (usually from CRLs of all authorities in the chain) to check if any of the certificates in the chain are still valid.
If there are links to OCSP in the certificates then the method could prefer to check OCSP status of these certificates but it depends on OS you are using (I think Win Xp didn't use OCSP but win 7+ does it by default).
If any of the checks the method performs fails, i.e. CRL not available or chain could not be built to a trusted root authority or certificate is revoked, then method returns false.
Related
When creating an intermediate root certificate, do you set the "IsCA" property of the certificate template? What exactly does this property do?
I'm creating a certificate chain for an application. In this application I need to use intermediate certificates to sign some client certificates. I've found some guides on creating Root CA certificates and they indicate to set IsCA = true when creating the certificate template, but I cannot find any information on creating intermediate roots. Does the IsCA property still need to be set? Are there any other changes to the certificate template when creating an intermediate certificate vs. a root certificate?
You must set the cA basic constraint for intermediate certificates. This bool indicates that a certificate can be used to verify other certificate signatures.
A certificate without cA set to true is a leaf certificate.
Here is the relevant portion of the "basic constraints" section of RFC 5280:
The cA boolean indicates whether the certified public key may be used
to verify certificate signatures. If the cA boolean is not asserted,
then the keyCertSign bit in the key usage extension MUST NOT be
asserted. If the basic constraints extension is not present in a
version 3 certificate, or the extension is present but the cA boolean
is not asserted, then the certified public key MUST NOT be used to
verify certificate signatures.
I have a server with a custom certificate on it issued by my own personal certificate authority. It's not on a public domain so it's not possible to use a standard certificate authority. I want to get an Android client to connect to this server using OkHttp. According to the docs, the code should look like this:
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("myserver.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.build();
Where the SHA256 hash is, quoting the docs: "a hash of a certificate’s Subject Public Key Info, base64-encoded and prefixed with either sha256/ or sha1/". I have the cert and the key files for the server, but how can I get the required hash?
I'm using OkHttp 3.
Try making a request to your server with the configuration above to see how that fails. The exception should tell you which pins were found.
You must do certificate pinning in coordination with your server team! Otherwise a change they make will prevent your client from being able to reach the server.
I added self signed certificate in .pem format in Firefox under Authorities tab. When I access site, Firefox throws error
mozilla_pkix_error_ca_cert_used_as_end_entity
It says that the certificate is not trusted because it is self signed. What can be issue?
If you add the certificate as authority then it should be used as authority, i.e. for signing other certificates. If you instead use it as a server certificate (i.e. as end entity and not authority) then it should not be added as authority to firefox but instead as server certificate. This will be automatically done if the certificate is not known and you click through the certificate error messages when connecting to your site and accept the sites certificate permanently.
You should also make sure that your certificates contains the necessary key purpose to be used as a server certificate.
I am currently developing an application that validates signature certificates (like in a pdf) with OCSP or CRL. These will most likely be leaf certificates, without the entire chain. Getting the url to either validation services proved simple enough.
To my understanding, both OCSP and CRL require the issuer of the certificate to validate it. So now I'm stuck because that is not included in the input. The AIA extension might include a URL to a CA certificate, but unfortunately this is the CA of the issuing certificate and not the certificate itself.
Is there any other way to get the issuer's certificate given only the leaf? Or are there some cases in which OCSP/CRL can validate without it?
Have a look at https://www.ietf.org/rfc/rfc2560.txt which details the requirements for an OCSP response to be considered valid:
The key
used to sign the response MUST belong to one of the following:
-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA
The first and third option both require the issuer cert. The second option does not. However I dont think that option is applicable to you situation. The link https://wiki.mozilla.org/CA:OCSP-TrustedResponder has details on what a trusted responder is and when it can actually be used.
I would like to ask when is the purpose of a certificate, like Server Authentication, Client Authentication, set for the certificate.
Is it when we generate the CSR or when it is signed by the CA?
The CSR is a Certificate Signing Request. If it is a PKCS#10 request (by far the most common type) it can indicate which extensions are requested and that can include the Extended Key Usage (aka purpose). But the CA ultimately decides what to include when it creates and signs the cert. It could choose not to issue a cert. It could issue a cert with a subset of the requested attributes. It could issue a cert that is completely different. It could issue a cert that is exactly what the CSR requested.