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.
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 am trying to implement a (simplified) RSA-like verification process in my (Java) application.
The client sends a request (data + private key signature) and the server either rejects his request or processes it - depending on the signature validity.
But I don't understand how the verification server knows which public key to use for signature decryption. Indeed, no public key - nor public key ID - seem to be sent to the verification server.
Does it actually test all authorized public keys ? Or is the public key stored from a previous communication exchange ?
The figure has several errors and some omissions, because it is probably a simplification:
the hash is digitally signed, not encrypted, and the signature is verified, not decrypted. The underlying cryptographic operation is not equivalent.
the signed data should include the certificate and the certification chain
if you use a known format like CMS, pkcs#7 or XMLDsig the hash to sign usually includes also a reference to the signing certificate and content-type to avoid tampering
To validate a signed document you verify the signature using the public key of the attached certificate but it is mandatory to check that the signing certificate is trusted verifying that the certificate itself or the issuing Certification Authority is present in the client's trustore.
The signature includes the certification chain because usually the truststore does not contain the intermediate CAs. The certificates of the truststore are exchanged previously
Additionaly the verification process should check that the certificate is not expired and not revoked
Note that the verification process is the same for all digital certificates in a public key infrastructure, not just RSA
As the figure you attached with the question suggests, the client sends its certificate along with the signature, the certificate contains the public key, the server checks for certificate validity and uses it to check the signature.
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.
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."