Referring to the Azure keyvault Sign API at https://learn.microsoft.com/en-us/rest/api/keyvault/sign/sign. Its not clear if the "value" which is string (in request and response both), how the API expects the encoding for binary strings like digest and how the response has this 'value' encoded? Is this in base64? If so, Azure has any difference in base64? Any sample code showing this REST API request/response processing?
Looking for help in understanding how (and if) we can use the ‘Sign’ API to sign the X509 digital certificate.If we generate or upload the Keys (private key – corresponding to the root CA cert), can that key be used to sign a digital certificates issued by this CA. If so, what would be the right steps to do this. In my understanding, take the digest of the x509->cert_info, encode this digest in base64 and call Azure 'sign' API. Once we have the response, append the signature to X509 certificate (that was being signed i.e. x509->signature with this signature). Would be great if you could share code example.
Related
I am not sure if this is a duplicate of Sign a CSR with Azure Key Vault, but I am surprised not to see any solution to this request.
AWS Certificate Manager can act as private CA, I would expect something similar in Azure, but I can't find anything.
Assuming I have a csr, how can I get it signed by own CA?
I see two approaches:
I store the CA certificate in Keyvault and then download the private key to sign. This is bad, because the private key leaves the vault.
I store the private in the Keyvault and then use the sign() method to sign the csr digest.
I am suprised to see that there is no simple method to sign the csr and get the signed certificate. The approach 2. would require manual steps to build the certificated from the signed digest.
Is there any alternative or ready library to sign csr?
Thanks for any hint,
I am working on a project using TPMs & am trying to figure out if the AIKs can be used to decrypt any blob of text?
I was able to get my head around AIK enrollment & am now trying to use it for identity. For that my plan is to send a blob of text encrypted with AIK public key & ask the platform to decrypt it for me.
I thought of an alternate approach to have the AIK sign a blob of text for me at first, but looks like AIKs can be used to sign only the PCRs.
No, as a signing key the AIK is not meant to be used for decryption. You may be misunderstanding the purpose of the AIK. It is almost exclusively used for signing system quotes (obtained via TPM_Quote) which is then checked against the AIK certificate signed by a CA you trust. Intro to TPM 1.2 explains well how the EK and AIK play together.
I know a bit of authentication theory, but would like to know how is it really put in practice.
There are these software patches that must be distributed periodically. To ensure that only the genuine content reaches our users, we have been advised to sign our content before distribution.
The plan is to generate a Public-Private key pair. The patch would first be signed by our private key and recipients then authenticate the downloaded patch by using our public key. Our idea of signing is to generate a hash of the patch and encrypt the hash with our private key. The encrypted hash (signature) is to be bundled along with the patch before distribution.
We have been advised further that it is a good practice to get a digital certificate for our public key from a CA and post it on a certificate server in our premises. We are told that the CA would create this certificate using its private key. Our users are expected to download the public key certificate from our server and authenticate it using the public key of the CA. Thus our users would be confident that they have the right public key from us to authenticate the genuineness of the patch.
And finally the question:
How/where can the exact public key of the CA be downloaded for authentication of the public key certificate downloaded from our server?
In what formats are these certificates available? Are these plain text files or XMLs or ??
To answer your questions in order:
Using a browser and SSL. In that case you rely on the certificate store already in the browser. It may be a good idea to also publish the fingerprint of your own certificate. Note that you also distribute a certificate - or certificate chain - within your software. If the software download is trusted, then you may not even need an external Certificate Authority. But in that case you keep your private key of the CA very secure.
X5.09 certificates are created using ASN.1 DER encoding. DER is a binary encoding (and the textual ASN.1 definitions specifies the contents). Certificates are also often distributed in PEM format. This is a base 64 encoding of the binary certificate, with an additional header and footer.
I am using Azure ACS with my MVC4 client using passive redirection. I've configured Azure to issue JWT, and I'm using the new WIF JWT library for validating the token. This is all working just fine.
The problem that I am encountering is that Azure signs the JWT with the X.509 Certificate, rather than the Symmetric Key, which requires my MVC application to have the Certificate, which is annoying at the moment.
I know that the JWT support is in Beta, and that there are security issues with using a Symmetric Key (in that anyone with the Key could fake a token).
Is there some setting that I am missing? I tried making the Certificate the "Secondary" signing key in Azure, but this had no effect.
ACS chooses keys to sign a JWT in the following precedence order:
Relying party symmetric key
Relying party certificate
Service-wide certificate
What you don't see anywhere on this list is a Symmetric service key, because there are security issues with using a symmetric key between more than two entities.
What this means is that your key needs to be associated with the relying party, not the namespace, as in the following screenshot.
I imported a third party CA issued PFX certificate using PFXImportCertStore. Upon successful importing, the PCERT_KEY_PROV_INFO_PROP_ID is set to the following values by default by the same call, PFXImportCertStore
Why is the dwKeySpec recognised as AT_KEYEXCHANGEkey type rather than AT_SIGNATURE?
Why is the pwszProvName set to Microsoft Base Cryptographic Provider v1.0?
The certificate in the first place was issued ONLY for Digital signing. But the key usage field indicates that the certificate can be used for Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0). Enhanced key usage indicates, Client Authentication and Secure Email? Has the CA has issued the certificate correctly? The front of the certificate shows the following message(screen shot below) which makes me to suspect that this certificate was not issued for digital singing? Am i thinking correctly or not?
4.Because of these issue, i am unable to sign data using CryptSignMessage. The internal call fails to acquire context to the private key for signing. Any suggestions on how i can get around this issue?
I am able to sign with a selfsigned PFX cert which i generated. Do you think that i could export the private key in to new container and set it property to AT_SIGNATURE and the csp provider Type to PROV_RSA_AES, as i require SHA256.
I am working with XP sp3.
Thanks
Answer 1: The key is automatically classified as AT_KEYEXCHANGE because, its usage is also to encrypt session key etc. ie Though my application's main purpose is to digitally sign data, the CA has defined the key usage policy to include encipher, which forces CryptoAPI to map the key type to AT_KEYEXCHANGE.
Answer 2: I ASSUME that it is a default csp in this machine, so...? Any better explanation, please
Answer 3: From many replies from guys in Crypto Google group, AT_KEYEXCHANGE key can also be used to sign data, provided your certificate's key usage allows you to do digital signing. It seems to be common practice for third party CA's to issue certificates that can be used for multiple purposes. So the third party CA has issued the certificate correctly.
Answer 4: I managed to sign data using CryptSignMessage with the same third party issued certificate. I changed the dwProvType in PCERT_KEY_PROV_INFO_PROP_ID to PROV_RSA_AES and passed in NULL for pwsProvName. This change is performed by using CertGetCertificateContextProperty first to get the properties and then using CertSetCertificateContextProperty to set the properties of your choice. This fixed the signing issue. Now i am able to sign with SHA256/RSA1024, AT_EXCHANGE key.