I'm researching CMP with EJBCA 4.0.12 and ejbca 6 according to rfc 4210, the key pair used for cert can be generated in client RA, CA. My problem here is that when operating with RA mode, then sending a request to CA for certificate requests, I don't know how to generate key pair for that client from CA. Please show me that how I have to do to generate in that case
Related
I am trying to generate X509 certificates in C# code (using the X509Certificate2 class) and upload them to an Azure Key Vault.
I have found out that if my certificate contains the flag X509KeyUsageFlags.KeyEncipherment, the vault will reject the certificate with this error message:
Unsupported key operation(s): "wrapKey", "unwrapKey". Supported values are "sign", "verify".
Does anyone know what to do about this? Of course I can remove that flag from my generated certificates, but I want to understand why Azure rejects it. Is it possible at all to upload certificates to an Azure Key Vault when they contain this flag?
I ahae read this documentation page, but it did not tell me much: https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys-details
(This is a more specific follow-up to my earlier question here.)
• You are encountering this issue because the key along with this x509 .pem certificate is not in correct format and not combined with the certificate. That is, the certificate type that you are importing should not have its information contained in it in base64-encoded byte form. It should be in its raw form.
Thus, the error signifies that the certificate key you are trying to import is to be used to sign and verify the application content and the application using this certificate will hash the data locally using the certificate’s keys. Thus, the certificate key should not itself be in other unacceptable form. Also, the key generation algorithm may not be supported as stated from the error that you are encountering.
• Hence, if you are importing a certificate in PEM(whether that be X509 certificate) format, then "contentType" should be "application/x-pem-file" type. The value parameter will just be the raw text contents of your PEM file and need not to be in base64-encoded-byte, because PEM certificate is already in a text format, so base64-encoding is not required. Thus, the private key of the certificate should be in the same format as the certificate contents encryption algorithm. It need not be masked or converted in another format and it should be combined with the certificate itself.
Please refer to the links below for more information: -
https://learn.microsoft.com/en-us/azure/key-vault/certificates/certificate-scenarios#formats-of-import-we-support
https://learn.microsoft.com/en-us/answers/questions/258583/import-certificate-api-for-azure-key-vault.html
I'm creating a coap server with DTLS as security layer that will use digital certificates, x509.
The Coap Server is a data bridge to a cloud server (CA) that uses x509 as authentication.
I also have a device that directly connects to the Cloud server using the same authentication method.
A couple of functions of the device, also needs to communicate with Coap server.
Thus the cloud server is the CA for issuing digital certificates both the device and the Coap data bridge.
I wanted to reuse the certificates (used to communicate to the Cloud Server) in device for connecting to the Coap server. Since the the device is a constraint thing, having multiple certificates are not advisable. Is this possible?
Yes, but there are some pitfalls:
RFC7252 - DTLS - x509
Implementations in Certificate Mode MUST support the mandatory-to-
implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified
in [RFC7251], [RFC5246], and [RFC4492]. Namely, the certificate
includes a SubjectPublicKeyInfo that indicates an algorithm of
id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the public key
format is uncompressed [RFC5480]; the hash algorithm is SHA-256; if
included, the key usage extension indicates digitalSignature.
Certificates MUST be signed with ECDSA using secp256r1, and the
signature MUST use SHA-256.
So, you either use ECDSA (ECC certificates, not RSA), or you need to check, if your server is able to handle it. For Eclipse/Californium the node's certificate must be ECDSA, the other certificates in the path may use other algorithms, if they are supported on your platform.
By the way, I'm not sure, if you really benefit from x509, but that depends on the platform your using on your devices.
X509 certificate and key could be used for several purposes. Examples include,
digital signature
key enciphering purposes
data enciphering purposes
key agreement
so on and so forth
More details could be found here
Now, as per to the description of your problem, you are inquiring whether to use the same certificate/key pairs for both to
Authenticate against the cloud server
Use it for communication ( Encipher/Decipher) purposes with the COAP server
Ofcourse you can use it as long as the (KeyUsage) extension specifies the intended use of the certificate. Refer link above for KeyUsage extensions in X509 certificates
I am looking at a clear answer on to how to renew the CA successfully in EJBCA. We have thousands of client certificates already issued by the EJBCA which is actually working as a subCA signed by an external CA. The process is indeed documented here https://www.ejbca.org/docs/Renewing_a_SubCA_Signed_by_an_External_CA.html but it does not state clearly, what will happen to the already issued client certificates. Will they continue to be successfully validated via the new CA?
That link give two options for renewing the key:
1. Using the same CA signing key
If you refer to RFC 3647, this is the correct definition of a renewal. In this case, the keys remain the same and the certificate Subject remains the same. Effectively, the new certificate is the same as the old albeit with different dates.
Relying parties will trust this certificate in the same way as they trusted the original.
2. Generating new CA signing keys
The correct term for this is a re-key. The key changes and the Subject stays the same. The certificate is a different certificate as far as any relying parties are concerned. This may mean more work for you.
You'll first need to ascertain what will happen to the original CA certificate. Will it expire or be revoked, or will it still be valid?
If it's being retired, you'll need to replace all certificates issued by that original CA certificate as they will only verify through the original CA.
If not, and you're re-keying for other reasons, for example the original CA certificate's CRL has become too large to manage, then there is no need to rush into replacing all your subscriber certificates. The old CA certificate will still verify those certificates, while subscriber certificates issued by the new CA certificate will be verified by the new CA certificate.
Openstack Keystone PKI uses two certificates as this document mentions:
https://www.mirantis.com/blog/understanding-openstack-authentication-keystone-pki/
CA certificate and the signing certificate.
My understanding so far: Signing key is used to sign the user token while the signing certificate contains the corresponding public key and will be shared with the service endpoint to be used while decrypting the user token.
Is this correct? If so, what is the purpose of the CA certificate and the CA key?
I'd suggest the OpenStack documentation at http://docs.openstack.org/admin-guide-cloud/content/certificates-for-pki.html
PKI stands for Public Key Infrastructure. Tokens are documents, cryptographically signed using the X509 standard. In order to work correctly token generation requires a public/private key pair. The public key must be signed in an X509 certificate, and the certificate used to sign it must be available as a Certificate Authority (CA) certificate.
Tokens are both signed and verified. There's no decryption.
The certificate and certificate authority used can be internal or external and how the cloud provider choses to configure it is up to them.
In PKI environment certificate(signing cert) is signed by CA. CA is usually external entity but if you use keystone-manage pki_setup to generate the signing keys it first setup the CA locally and sign the certificate which keystone uses.
CA key is used for CA, keystone do not have any use of it.
Keystone just need own private key, Signed Certificate and CA certificate.
Hope this is useful.
-Thanks
I am developing mdm server and I have a problem with one of enrollment steps. The problem is scep step. I implement a scep server which handles Device CACert request and sends our server certificate in der format. After that, device sends encrypted and signed csr. But I can not verify signature of message. I think device creates a self-signed-certificate and sign message with it. We think that because signature certificate's common name is changing each "PKIOperation" request. But we must verify this signature because of security.
For example in each 3 enrollment request, certificate of csr signature changes. Their common names are:
CN=6E4F65AD-1E64-4E4D-A96E-2039EB140041
CN=2E33C2CC-14B8-47AC-938B-DCC7F8DA8715
CN=6817ED48-AB79-4FF0-A1A9-42C2AC303672
Note: The other steps of enrollment device sign messages with proper certificate and I can verify them. Only scep PKIOperation request is my problem. Is there any profile flag to set or something to solve this problem?
I may be wrong in some details, because I touched this about two years ago.
However, as I remember it's part of a protocol
If you take a look at SCEP draft: https://datatracker.ietf.org/doc/html/draft-nourse-scep-23#page-30 you will see this:
When building a pkiMessage, clients MUST have a certificate to sign
the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires
it). Clients MUST either use an existing certificate, or create a
self-signed certificate (see Section 2.3).
If the requester does not have an appropriate existing
certificate, then a locally generated self-signed certificate
MUST be used instead. The self-signed certificate MUST use the
same subject name as in the PKCS#10 request.
However, I was under impression that iOS device uses certificate/private keys which are built into the device. And this certificate is signed using Apple certs. And actually, as I remember they had exactly the format of CN, which you shown.
So, generally speaking it's ok if device uses self-signed certificate for first communication to the SCEP server (PKIOperation) and uses a certificate issued by your CA later on.