Is the AuthorityInfoAccess field mandatory in x509v3? I have some certificates, and I'm trying to do OCSP verification, but they don't seem to have this field when I do
openssl x509 -in file.cer -inform DER -text -noout
I was wondering if it's not in that output does that mean it's not there?
Neither extension is mandatory. All they are technically optional. But some applications may require the presence of particular extensions.
For example, for CA certificate it is required to have a Basic Constraints and KeyUsage extensions. Otherwise, the certificate would not be recognized as CA certificate.
In addition, when creating X.509v3 certificates, it is a good practice to include Subject Key Identifier to simplify certificate binding in the chain by using key match.
There are two cases when Authority Information Access (and CRL Distribution Points) should not be presented: in any self-signed certificates and OCSP signing certificates.
As you are talking about OCSP certificate, there is no practical need in this extension, because all required information is elsewhere. For example, if target certificate and its OCSP response are signed by the same CA, existing target certificate's chain is reused. If OCSP uses delegated OCSP signing certificate, then delegated certificate's chain is included in the OCSP response directly.
In practice, badly generated certificates doesn't contain Authority Information Access extension as well.
Related
RFC 5280 states:
CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority.
Q: Is there a standard way for a CA to "authorize" a particular CRL issuer that is not the actual CA?
In other words, if a CA certificate contains a CRL Distribution Point URL that contains a CRL that is signed by some key other than the SubjectKey of "this" cert (the one containing the CRL Distribution Point extension), how does "this" CA indicate the valid keys that can sign that CRL?
The CDP entry will contain a cRLIssuer value to indicate what the expected signer of the CRL at that location is.
Then the CRL had to assert that it is an indirectCRL via the Issuing Distribution Point extension.
If the CRL signer is subject is not the same as the issuing CA subject then both Windows and OpenSSL will stop at this point and pretend the CRL doesn’t exist (per https://security.stackexchange.com/questions/242185/deployment-tips-to-support-indirect-crls). But they do, per that question and answer, support the concept to let the CA use a different key for the CA and the CRL signing.
I have an ADFS that trusts a SP.
I added the signature verification certificate
for my relying party trust but I get the following error:
MSIS7093: MSIS7093: The message is not signed with expected signature algorithm. Message is signed with signature algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1. Expected signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
It seems pretty clear, but not coherent with the actual context: the signature verification certificate is generated by SHA-256, not SHA-1.
If I follow right the error message and change the secure hash algorithm from SHA-256 to SHA-1, it works and I can perform the SSO authentication. But I'm not happy with that, for two reasons:
SHA1 is not safe anymore
I don't know why I should set the secure hash algorithm to SHA-1 when the certificate used is actually in SHA-256.
The certificate was generated using openssl:
openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout samlkratos.key -out samlkratos.crt
Does anyone have any idea why that happens?
The hash of the certificate is not really related to the hash being used to has the data.
For instance when XML is signed, the canonical XML is hashed using one of a number of supported hash algorithms. The XML is then updated with the Signature Algorithm like http://www.w3.org/2000/09/xmldsig#rsa-sha1 to tel the server that this is the algorithm that was used.
In the server side there is often a setting at the IdP where the Signature Algorithm is specified. Essentially telling the IdP that it should be validating the request with a specific algorithm
If you are sending sha1 and the error is that it was expecting sha256 there is a mismatch and the SP (the application) likely needs to have the setting changed.
You can normally se what is being sent from the browser with a SAML decoder plugin.
Again it depends what the SP application is configured to send and what the IdP is configured to accept (if applicable) and has very litly to do with the certificate (the RSA in rsa-sha256) requires a RSA based certificae but the has can be a number of things as long as the combination is supported (example a DSA certificate cannot support sha512 since the specification does not allow it)
I want to generate a digital certificate for signature and authentication to sign a document, but I couldn't find any validated authority in my country that delivers digital certificates. In such a case, is there any way (website) to generate this type of certificates?
Thanks
You can create self signed certificate as described for example here How to generate a self-signed SSL certificate using OpenSSL?. Downside is that the Adobe Reader shows the signature invalid as by default it is not trusted.
You can also buy the "Document Signing Certificate" from any trust service provider. You will get USB crypto token with that. In this case Adobe Reader will show the signature valid.
I was working on a sample TLS client/server program to perform certificate validation.
For a self signed certificate validation, these are the steps i followed.
#server side:
Generated a server key file serverkey.key
Generated a CSR certificate servercert.csr from the key file.
Digitally signed(using openssl x509 utility) the servercert.csr using a
generated rootCA.key and rootCA.cert. server certificate file servercert.cert
is generated.
Loaded the certificate file(servercert.cert) and key file(serverkey.key) using
SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey openssl apis.
#client side:
Loaded the server ca-file --> rootCA.cert (which was manually copied to the
client) using the SSL_CTX_load_verify_locations api.
Using the SSL_get_verify_result() api validated the certificate that server
sends in the Certificate message.
The question that i have is that if i use a trusted CA(like godaddy) to sign a server CSR certificate, will the CA be providing its public key file (something similar to rootCA.cert) as well which was used for signing ?
By which i can load the same to the trusted list at client side using SSL_CTX_load_verify_locations api.
My intention is to keep the code unchanged regardless of being a self signed certificate or a valid CA provided certificate.
When (any) x509 certificate is generated, these things happen:
Private key is generated
Public key (associated with the private key mentioned above) is embedded in the new certificate (becomes an integral part of it)
The new certificate is signed using private key of the issuer (read: CA)
In order to verify the certificate integrity (to check if nobody tampered with it) - you need to verify the signature (created using issuer's private key - see 3)). To be able to do it you need to obtain (somehow) the issuer's public key. This key is embedded in the issuer's certificate (see 2)). Usually the trusted CAs' certificates are stored in so called trusted certificate store. In case of OpenSSL you specify this "store" by using SSL_CTX_load_verify_locations function (and a few other simmilar functions - consult OpenSSL documentation).
To summarize:
In your case the location pointed by SSL_CTX_load_verify_locations should contain your CA's certificate(s) - all of them - the whole certificate chain up to the self-signed root certificate. You can obtain all of the certificates in the chain from your CA (in your case GoDaddy).
I hope that helps.
If I can clarify anything more please ask.
Is it enough good to buy SSL X509 certificate for SAML 2.0 SP encryption and signing or I have to look for other certificate type such as Code Signing Certificate ?
You do not need a code signing cert.
Depending on how you've set up trust/which bindings you use/federation rules you could get away with a self signed cert. The answer is it depends, but a standard CA issued cert should be fine for the majority of use cases.