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.
Related
I'm studying Azure IoT Hub and trying to connect my device to IoT Hub with x.509 certificate.
It worked with self-signed cert, but the official suggestion is to purchase a root CA cert from a trusted third party to sign device cert.
Get an X.509 CA certificate
I did some research, but couldn't find where to purchase.
Can you give me a link? And how much will it cost?
You probably don't want a root CA cert, as those are not available to anyone but the certificate authorities themselves.
What you seem to be looking for, is a certificate signed by a root CA.
You can get one from let's encrypt, or from any of the commercial CAs like Verisign, Thawte, etc.
A word of warning. If you purchase a certificate from a certificate authority that has been signed by a trusted root and you intend to use that to sign device s' X.509 certificates for authentication, make sure that you do not purchase an end entity certificate. That type of certificate is incapable of signing another certificate and will not work. Make sure the certificate you get is capable of signing other certificates.
AWS has it's own CA. Because AWS thinks security is important and they are capable of a decent cloud product implementation.
Microsoft on the other hand is more worried about selling defender security E5 licenses, so security implementations are weak or require premium licenses. No account expiring, no Azure CA for devices.
This 3th party can fix your problem for IOT Hub.
https://www.globalsign.com/en/blog/integrate-microsoft-iot-azure-iot-hub-and-provisioning-service
https://www.deviceauthority.com/solutions/keyscaler-identities/
https://www.keyfactor.com/platform/iot-identity-platform/
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.
Let's say we have a server only running REST API services, only on HTTPS.
The only consumer of the APIs is a mobile app.
Do we need certificate from CA or a self signed certificate is enough?
You will need to use a CA certificate. Otherwise, each mobile client will have to manually set your certificate as trusted.
You can potentially embed the certificate as trusted in the mobile app itself (assuming you distribute the app), however it will be a problem when the time comes to renew the certificate, or rekey/replace the certificate for whatever issue.
Using a globally trusted certificate is the way to go.
You can :
Keep a self-signed certificate, but then you have to pin the certificate, and you can't revoke it if the private key is compromised.
Use a home made certificate authorities, but then you have to pin the certificate, and manage the revocation process (maintain an OCSP or CRL).
Use a certificate from a trusted CA, revocation will be checked for you, and if you want additional security, you still can pin the certificate.
In my opinion, the use of a trusted CA is more secure and more simple.
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.
From ADFS and ADFS 2.0 perspective is it possible to register Service Provider metadata that is using certificate (public key) that is not issued by signing authority ? I mean on self signing certificate.
Yes - you can use a self-signed certificate for the SP and that certificate is reflected in the SP metadata.
So you can generate it with the Java keytool etc.
Also ensure that you generate the certificate for a reasonable period - at least a year otherwise you will have to co0ntinually update the metadata on the ADFS side.
It should not be as described in following document -
Certificate Requirements for Federation Servers in section Determining your CA strategy
"ADFS does not require that certificates be issued by a CA. However, the SSL certificate (the certificate that is also used by default as the service communications certificate) must be trusted by the ADFS clients. We recommend that you not use self-signed certificates for these certificate types."