I'm following this tutorial and app works, but certificates I created with my server key works
I understand that I need to pass ca option with certificates my server accepts, but I don't know how to specify what I need.
I would like to accept certificates from other CA, not only the ones signed with my server key.
[The peer's certificate must be chainable to a CA trusted by the server for the connection to be authenticated. When using certificates that are not chainable to a well-known CA, the certificate's CA must be explicitly specified as a trusted or the connection will fail to authenticate.][1]
const opts = {
key: fs.readFileSync('server_key.pem'),
cert: fs.readFileSync('server_cert.pem'),
requestCert: true,
rejectUnauthorized: false,
ca: [ fs.readFileSync('server_cert.pem') ],
}
How can I do this?
It depends on how you're validating, but at the very least you would need to have a .CER copy of the other CA certs installed in your machines certificate store in the trusted root certification authorities folder. After that it'd all fall down to validation. Some validation methods automatically query your machines cert store for the certificate. Or you can programmatic it to pull the CA from your certificate store and construct the chain yourself.
The .CER version of the certificate refers to the public copy that does not contain the private keys used for signing a certificate. This cert can validate other certificates that were issued by it, but it cannot sign a certificate.
If you're on a windows machine, you can access your certificate store through the Microsoft Management Console. Open a cmd prompt and type MMC.
Go to file > Add or Remove Snap In > Certificates and select Add. This will prompt you for the specific certificate store you want. If you click the drop down, you'll see additional folders. This will show all trusted certificate authorities in the given store. You will need to add copies of the other CA signing certs here.
Related
I set http.sslbackend=schannel and imported my self-signed certificate into windows 10 (Personal | Certificates) pane in MMC. Now, I'm trying to clone a repository hosted on a server configured with the self-signed certificate.
As far as I understood as long as having the certificate in windows (explained above) git should not complain about the certificate. This is not the case. whenever I try to clone I'm getting:
unable to access https://server.com/project.git : schannel: SEC_E_UNTRUSTED_ROOT (0X80090325) - THE CERTIFICATE CHAIN WAS ISSUED BY AN AUTHORITY THAT IS NOT TRUSTED.
What am I missing here?
We need to communicate between our ec2 server and our customer server via Mutual TLS.
The requests are sent from our server to our customer server - so we are the client here.
I read this post, talking about how to generate the files.
The first step is to create a certificate authority (CA) that both the
client and server trust. The CA is just a public and private key with
the public key wrapped up in a self-signed X.509 certificate.
Our cert and their cert - should be signed from the same root CA? who should provide it?
The code in my side should be like:
const req = https.request(
{
hostname: 'myserver.internal.net',
port: 443,
path: '/',
method: 'GET',
cert: fs.readFileSync('client.crt'),
key: fs.readFileSync('client.key'),
ca: fs.readFileSync('ca.crt')
},
res => {
res.on('data', function(data) {
// do something with response
});
}
);
So what should we provide each other? We don't exactly understand and they are not providing more details, just asked us to give them a certificate...
Our cert and their cert - should be signed from the same root CA? who should provide it?
Since the control of the client certificate is done at the TLS server side (i.e. at the customer) it depends fully on what they expect. They might require a publicly signed certificate, they might require a certificate signed by their own CA. Or they might simply check that a specific certificate gets used and will also accept self-signed certificates for this.
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 have installed SSL successful in my azure server but it's not binding with domain. I am getting following error message.
It is not clear on what certificate you are using. To use a certificate in App Service, the certificate must meet all the following requirements:
Signed by a trusted certificate authority
Exported as a password-protected PFX file
Contains private key at least 2048 bits long
Contains all intermediate certificates in the certificate chain
As highlighted by Snobu you may regenerate the certificate (for Self-Signed) with: extendedKeyUsage = critical,codeSigning,1.3.6.1.5.5.7.3.1 in the x509_extensions in the file. Refer this document for the step-step instructions on uploading a certificate.
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)