I'm trying to send a pkcs10 CSR to a CA but need to define the life/validity of the certificate and override the profile information created in the CA. I'm using BouncyCastle 1.55 and org.bouncycastle.pkcs.PKCS10CertificationRequestBuilder.
Thanks in advance of the help!
pKCS#10 may set some attributes that CA could include (or not) in the certificate. But the validity of the certificate is not one af those fields. You can see the list of.available in the PKCS#9 RFC
The information about the validity period (lifetime) is not part of the certificate signing request - also not listed as optional attribute in PKCS#9.
Extract requested validity period from a Certificate Signing Request using OpenSSL
Related
This is a theoretical question about certificate validation in Hyperledger Fabric. How does Fabric handle a scenario like a compromised certificate authority? Does it monitor public log servers to ensure a certificate is valid?
Certificate Revocation Lists
A Certificate Revocation List (CRL) is easy to understand — it’s just a list of references to certificates that a CA knows to be revoked for one reason or another. If you recall the store scenario, a CRL would be like a list of stolen credit cards.
When a third party wants to verify another party’s identity, it first checks the issuing CA’s CRL to make sure that the certificate has not been revoked. A verifier doesn’t have to check the CRL, but if they don’t they run the risk of accepting a compromised identity.
Using a CRL to check that a certificate is still valid. If an impersonator tries to pass a compromised digital certificate to a validating party, it can be first checked against the issuing CA’s CRL to make sure it’s not listed as no longer valid.
link: https://hyperledger-fabric.readthedocs.io/en/release-2.2/identity/identity.html#certificate-revocation-lists
Generating a CRL (Certificate Revocation List)
After a certificate is revoked in the Fabric CA server, the appropriate MSPs in Hyperledger Fabric must also be updated. This includes both local MSPs of the peers as well as MSPs in the appropriate channel configuration blocks. To do this, PEM encoded CRL (certificate revocation list) file must be placed in the crls folder of the MSP. The fabric-ca-client gencrl command can be used to generate a CRL. Any identity with hf.GenCRL attribute can create a CRL that contains serial numbers of all certificates that were revoked during a certain period. The created CRL is stored in the /crls/crl.pem file.
The following command will create a CRL containing all the revoked certficates (expired and unexpired) and store the CRL in the ~/msp/crls/crl.pem file.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl -M ~/msp
The next command will create a CRL containing all certificates (expired and unexpired) that were revoked after 2017-09-13T16:39:57-08:00 (specified by the –revokedafter flag) and before 2017-09-21T16:39:57-08:00 (specified by the –revokedbefore flag) and store the CRL in the ~/msp/crls/crl.pem file.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
The –caname flag specifies the name of the CA to which this request is sent. In this example, the gencrl request is sent to the default CA.
The –revokedafter and –revokedbefore flags specify the lower and upper boundaries of a time period. The generated CRL will contain certificates that were revoked in this time period. The values must be UTC timestamps specified in RFC3339 format. The –revokedafter timestamp cannot be greater than the –revokedbefore timestamp.
By default, ‘Next Update’ date of the CRL is set to next day. The crl.expiry CA configuration property can be used to specify a custom value.
The gencrl command will also accept –expireafter and –expirebefore flags that can be used to generate a CRL with revoked certificates that expire during the period specified by these flags. For example, the following command will generate a CRL that contains certificates that were revoked after 2017-09-13T16:39:57-08:00 and before 2017-09-21T16:39:57-08:00, and that expire after 2017-09-13T16:39:57-08:00 and before 2018-09-13T16:39:57-08:00
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --expireafter 2017-09-13T16:39:57-08:00 --expirebefore 2018-09-13T16:39:57-08:00 --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
link: https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#generating-a-crl-certificate-revocation-list
Besides that, Hyperledger Fabric provides Pluggable Consensus Protocol and the security is depends on your plugable MSP too.
I am currently building a webservice that should handle Alexa voice intents. The HTTP request I get from Alexa must be verified by checking a signature, as described in the documentation (see below for excerpt).
Various info:
certificate chain file:https://s3.amazonaws.com/echo.api/echo-api-cert-5.pem
Original received signature for the above example signature:
LqhhuCKwBRVucGS1MHS2yf3jKMmpm10cuImDnK0bC8lQHLfCbMukdHhvulWH4SAypXqgAk3y81G0CRS4NIG+oLnTB3PfeHb70yS8WdSFflKd/NlTc/2Rr1c5pCdpZ9C1LtNmsa/pSafTbSt4RDhmQ8XtKVCw6twhTsebS6om6/ggom95z3m1Zi4k4SkLKRQGvq18+sJHcsADKHrLO735FQ3CNrIVfS76UMXkROlJ9oSEBa9KpqSONffdVe7DDBGTGF4CLjfoSDDBjQ1nCQ0THxljUdTZ2kp4cYn1qkXJfCPoLB2+75O6Cndf+BMP9+gWd20Rl5GV44KLY9ezwEmYpA==
Excerpt from the Alexa documentation:
Checking the Signature of the Request
Requests sent by Alexa provide the information you need to verify the
signature in the HTTP headers:
SignatureCertChainUrl Signature To validate the signature:
Verify the URL specified by the SignatureCertChainUrl header value on
the request to ensure that it matches the format used by Amazon. See
Verifying the Signature Certificate URL. Download the PEM-encoded
X.509 certificate chain that Alexa used to sign the message as
specified by the SignatureCertChainUrl header value on the request.
This chain is provided at runtime so that the certificate may be
updated periodically, so your web service should be resilient to
different URLs with different content. This certificate chain is
composed of, in order, (1) the Amazon signing certificate and (2) one
or more additional certificates that create a chain of trust to a root
certificate authority (CA) certificate. To confirm the validity of the
signing certificate, perform the following checks: The signing
certificate has not expired (examine both the Not Before and Not After
dates) The domain echo-api.amazon.com is present in the Subject
Alternative Names (SANs) section of the signing certificate All
certificates in the chain combine to create a chain of trust to a
trusted root CA certificate Once you have determined that the signing
certificate is valid, extract the public key from it. Base64-decode
the Signature header value on the request to obtain the encrypted
signature. Use the public key extracted from the signing certificate
to decrypt the encrypted signature to produce the asserted hash value.
Generate a SHA-1 hash value from the full HTTPS request body to
produce the derived hash value Compare the asserted hash value and
derived hash values to ensure that they match
Then I used the verify method in class SkillRequestSignatureVerifier provided by Alexa SDK, but it didn't work.
Which decoding way should I use to realize what it says:
Use the public key extracted from the signing certificate to decrypt
the encrypted signature to produce the asserted hash value.
And he say :
Generate a SHA-1 hash value from the full HTTPS request body to
produce the derived hash value.
But I don't find it. Please help me to solve this problem!
I have created a key-pair and now I want to bind my public key with an email id (create a digital certificate). I do not want to do the next step of signing the certificate.
Question: How can I create the digital certificate (hence bind the public key with the identity) and not really sign it for now ? (Using OpenSSL for the same would be fine).
My understanding:
Digital certificate is just packaging the public key with an
identity.
Digital signature is a CA assuring/signing the
certificate and embedding the signature in the certificate file
Or is my understanding all wrong ?
Signature is a required part of certificate. You may instead create so-called self-signed certificate, signed by your own key.
if i got your question right, you want to prepare a certificate and stop the process before the actual signing by a CA would happen ...
the thing you are looking for is a so called certificate request ...
have a look at the "openssl req" command ... for examples see http://www.openssl.org/docs/apps/req.html (examples section shows generating a new request)
I have an trusted Certificate given by user (may be self-signed). I want to use that certificate to validate https server certificate chain.
I found there was code example like:
Validate X.509 certificate against CA in Java
which only validating if last certificate certs[0] is signed by given certificate.
Following link is using CertPathValidator to validate the certificate.
Java X509 Certificate parsing and validating
Which example should I follow? I suppose if any certificate in certificate chain is signed by given certificate, the validation is passed, is it right?
These two actions seem to do the same:
using the Basic Constraints extension in a X.509 Certificate to signify that it is a CA certificate and
using the Key Usage extension e.g. to signify that the public key can be used for certificate signining.
What is the difference between these extensions?
Do they serve same purpose or complement each other?
"Key Usage" defines what can be done with the key contained in the certificate. Examples of usage are: ciphering, signature, signing certificates, signing CRLs.
"Basic Constraints" identifies if the subject of certificates is a CA who is allowed to issue child certificates.
For a certificate that can be used to sign certificates, the info is in some sense duplicated:
X509v3 Basic Constraints: CA: TRUE --- Can sign certificates
X509v3 Key Usage: Key Cert Sign --- Can sign certificates
But "Basic Constraints" will also specify the maximum depth of valid certification chain.
Though it is duplicated, you need to specify both, according to RFC 3280 --- X.509.
This is the relevant paragraph from the RFC (page 29):
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted.
Key Usage describes intended purposes of the certificate.
Basic Constraints extension describes how deep the certificate chain that has the certificate as it's top can be. In other words, this extension is used by CAs to restrict activity of their sub-CAs when the sub-CA certificate is issued. If toplevel CA gets a sub-CA , it allows sub-CA to issue end-user certificates, but doesn't allow sub-CA have it's own sub-CAs.