I am generating certificates in Hyperledger Fabric using the Fabric CA. I am passing a self-signed certificate as the root certificate for both enrollment and TLS certificate issuance in HLF. It is for testing purpose and so same Fabric CA (single root certificate) is used to issue enrollment and TLS certificates. The root certificate has following Key Usages:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
In the node enrollment certificate, I have following Key Usages:
X509v3 Key Usage: critical
Digital Signature
Now, for TLS certificate I run the fabric-ca-client enroll command and pass --enrollment.profile tls as one the arguments to the call. When I decode the node TLS PEM certificate, I get the following Key Usages:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Now, I was referring one RFC here to identify the Elliptic Curve Cryptography Subject Public Key Information. In section-3, I read that Key Encipherment is not valid key usage extension for elliptic curve certificates. Through some more research, I also found that, Key Encipherment is used for symmetric key encryption (please correct me if I am wrong).
Now, my questions are:
Why is Fabric CA adding Key Encipherment as a key usage in the node TLS certificate if it is not according to the ECC RFC standards?
How does actually TLS communication happen in case of elliptic curve certificates and keys?
Fabric CA currently supports issuing both EC and RSA certificates. The default tls profile sets the key usages / extended key usages required for both.
If you want to limit the usages, you can edit the tls signing profile section in fabric-ca-server-config.yaml:
signing:
default:
usage:
- digital signature
expiry: 8760h
profiles:
ca:
usage:
- cert sign
- crl sign
expiry: 43800h
caconstraint:
isca: true
maxpathlen: 0
tls:
usage:
- signing
- server auth
- client auth
expiry: 8760h
Fabric CA only checks to make sure that the root cert has the CA constraint set too true. It does not limit the key usages for the certs it signs to it's own extensions (this is not technical required). If consumers of certificates wish to enforce usage constraints for the certificate based on the issuer as well, they do that themselves. openssl for example makes sure that a CA was allowed to sign certificates with the key usage it requires. It does not prohibit other extension though.
Related
Suppose I own a regular (non-wild-card) SSL certificate for example.com.
I want to become a Certificate Authority for all the subdomains of example.com. E.g. I want to emit a certificate request for wiki.example.com and sign it with private key of example.com, which was signed by Comodo/Thawte/whatever.
Would browsers consider cert chain wiki.example.com -> example.com -> Thawte a valid one?
No. Well, you can use the private key of you example.com certificate to sign a certificate for wiki.example.com and set example.com certificate as 'issuer' for wiki.example.com, but all browsers will reject such certificate chain.
The reason is that each certificate has "Key Usage" fields. Your certificate for "example.com" will have the following allowed usages:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
All reasonable SSL validator must reject this certificate as a CA certificate, since CA certicate must be
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
UPDATE
As #dave_thompson_085 mentioned, certificates must have field "Basic Constraints" that contains "CA" boolean flag. Bit flags "KeyUsage.keyCertSign" ("X509v3 Key Usage: Certificate Sign" in the Openssl output) and "BasicConstraints.CA" ("X509v3 Basic Constraints: CA" in the Openssl output) are asserted together (see RFC 5280, section 4.2.1.3).
The private key for example.com might be used for intermediate CA only when both bits are set.
I am setting up a IoT 2-way TLS authentication.
The common way is that both client- and the root (CA) certificate Private Key is RSA.
Now we have devices with limited memory, why we chose to switch to Eliptic Curve Private Keys on the client certificates in the IoT devices. The server certificate remained untouched (RSA).
From my understanding the handshake should succeed. Or do I understand anything wrong? Or do we have to switch the CA certificate to ECC as well?
After a quick test session: It IS possible to use a client certificate with a different private key algorithm than the Root Certificate on the server.
Client: OpenSSL
Server: BoringSSL
I have a self signed CA which has 1024 bit key length. Is it possible to sign a server certificate with longer key length (2048 bit) using this CA? I want to sign a server certificate and configure that for Active Directory service.
I'm able to do this using bouncy castle. My concern is about
1) Is this a good idea?
2) How would the certificate trust be established? Would that be okay.
Yes, you can use your 1024-bit RSA private key to sign a certificate for a server that is using a 2048-bit key. The length, and even the type, of the key in the certificate you're signing (the server's certificate) has no relation to the key you're using to do the signing. For example, you could have your 1024-bit RSA private key sign a certificate for a server using a 256-bit EC key if you wanted.
(Technically, you aren't signing the certificate itself, but a hash of the certificate. See this question and answer for details. But conceptually, you can think of it as "signing the certificate".)
Trust is established the same as with any other certificate chain:
Your client contains your CA's 1024-bit public key in its trust store.
Your client connects to a server, which sends its certificate, signed by your CA.
Your client sees that the certificate is signed by a CA in your trust store, so it verifies the CA's signature on the server's certificate using the CA's public key in the client's trust store.
The signature matches, so the client trusts the server's certificate.
I need information related to ECDSA certificates. As far as I know ECDSA certificate should contain the ECDSA signature but I see that facebook and google server certificates have the ECDSA certificates with RSA signature.
Is it possible to have the ECDSA certificates with RSA signatures?
The signature for a certificate is created by the issuer using the key of the issuer. Thus if the certificate A has an ECC key inside (i.e. ECDSA certificate) but the issuer B has an RSA key then the signature for A will be an RSA signature, because this is what the issuer has for signing.
For example in the case of facebook.com the certificate itself has an ECC key, but the issuers certificate DigiCert SHA2 High Assurance Server CA has an RSA key. Because the signature for the facebook certificate is done by the issuer with the issuers key it must use RSA too.
Steffen's answer is correct for X.509 standard and many browsers
which are based on standard SSL libraries support the case. However, in this rough real world, I found some devices rejecting ECDSA certificate which has RSA signatures, with TLS 1.2 negotiation.
I think the reason is that the authors of the devices followed the RFC-4492, (** is mine)
2.2. ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**
The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.
though RFC-5246, TLS1.2, loosened this restriction. (** is mine):
7.4.4. Certificate Request
...
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. **Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key). This is
a departure from TLS 1.1, which required that the algorithms be the
same.** Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate. Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the
extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.
So be warned that such a device exists.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I'm not clear on the difference between a CA key and a certificate. Isn't a CA key simply a certificate? Let me try and clarify with an example.
I have a client and a server. I'm only trying to validate my connection to my server and not trying to establish trust to others so I don't care about signing with a real CA.
Option 1: Generate a self-signed CA (ssCA) and use that to sign a certificate (C). I then install ssCA into the root keystore on my client and setup my server to use certificate C.
Option 2: Generate a self-signed certificate (SSC). Install SSC into the root keystore on my client. Setup my server to use certificate SSC.
The second option seems like a much simpler process. Should that still work?
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
You can openssl x509 -noout -text -in $YOUR_CERT to see the differences between files contents:
In your self-signed CA, you can seeļ¼
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
And in your self-signed certificate, it's:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.