Why does CertGetCertificateChain have a facility to return more than one"simple chain"? What are simple chains and what other type of chains should I expect?
On a test run passing a certificate such as the following...
root
|- parent
|- my certificate
...the result was one simple chain:
0. my certificate
1. parent
2. root
In what case will we see more than one simple chain returned?
Multiple chains may appear whan there are multiple paths from single leaf certificate through multiple CA certificates.
This occurs in two (major) cases:
two or more CA certificates share the same Subject and public key. This happens when CA certificate is renewed with the same key pair. This will result in two very similar certificates which can be used as a node in the certification path building. They are different, but they both (since Subject and public key are shared) can be used to validate the signature of the issued certificate.
when cross-certification is used to provide additional paths to (possibly) a different root certificate. Litreally the same as above, with the exception that this option is used to provide routes to different CA roots.
Single certificate chain is just single path from a collection of all possible paths.
Related
I'm copying files from an external companies bucket, they've sent me an access key/secret that I've set up as an env variable. I want to be able to copy objects from their bucket, I've used the below but that's for moving objects with the same connection, how do I use S3Hook to copy objects w. a different conn id?
s3 = S3Hook(self.aws_conn_id)
s3_conn = s3.get_conn()
ext_s3 = S3Hook(self.ext_aws_conn_id)
ext_s3 conn = ext_s3.get_conn()
#this moves objects w. the same connection...
s3_conn.copy_object(Bucket="bucket",
Key=f'dest_key',
CopySource={
'Bucket': self.partition.bucket,
'Key': key
}, ContentEncoding='csv')
From my point of view this is impossible. First of all, you can only declare one URL endpoint.
Secondly, Airflow S3Hook work with Boto3 in its background, and probably, both of your connections will have different acces_key and secret_key to create the boto3 resource/client. As explained in this post, if you wish to copy between different buckets, then you will need to use a single set of credentials that have:
GetObject permission on the source bucket
PutObject permission on the destination bucket
Again in the S3Hook, you can only declare a single set of credentials. You could maybe use the credentials given by your client and declare a bucket in your account with PutObject permission, but this will imply that you are allowed to do this in your enterprise (not very wise in terms of security), and even though your S3Hook will still only reference to one single endpoint.
To sum up, everything I have been dealing with the same problem and ended up creating two S3 connections using the first one for downloading from the original bucket and the second to upload to my enterprise bucket.
I'm going to store root and intermediate certificates (from different CA) into some KVStore.
The problem: I have a leaf certificate (only) that I want to validate based on certificates from my store. The leaf certificate has Authority Key Identifier == Subject Key Identifier of a parent that already must be present in the KVStore.
Question: What should I use as a Key in KVStore?
1.Subject Key Identifier:certificate or it can be the same within single CA or different CAs. what about renewal or keys rotation?
2.Subject Key Identifier + Subject DN: certificate - not sure that there is a difference with first.
3.Subject Key Identifier: list[certificate]
4.Serial Number + Issuer is unique but leaf certificate doesn't contain this date about parent.
The Subject Key Identifier is a hash value over the certified public key. Thus, depending on the CA's key rotation policy this may or may not change during certificate renewal. It is therefore not guaranteed that the mapping SKI:certificate is unique.
A combined index as in option 2 does not change that.
Option 4 should be ruled out since the child certificate does not know the issuer and serial number of its parent.
Option 3 may be a valid solution in most cases, however, the Authority Key Identifier extension is not mandatory for X.509 certificates. So you may have to deal with leaf certificates without the AKI extension.
This typically leads to option 5: Subject DN: list[certificate]. Preferably with a sorted list that has the most likely CA certificate on top.
However, if your application only deals with leaf certificates with an AKI extension and all CA certificates require a key rotation during renewal option 1 may be a tick more performant. In that case I'd also keep an entry Subject DN: list[Subject Key Identifier].
Why does the Node need the network-root-truststore.jks file at initial registration? What's the relashionship between this file and the nodekeystore.jks?
EDIT: Actually, I was meant that I didn't see the relashionship between the CSR and the network-root-truststore.jks file. Is it not possible to generate the Certificate Signing Request without this file?
network-root-truststore.jks-> This is the network operator's root CA.
nodekeystore.jks -> This contains nodes identity key pairs and certificates.
As you can see in the diagram. The Root CA for Doorman and Network Map are same. The node assumes 3 level hierarchy as you can see in the picture above. ( This got fixed in version 3.3 so you can have a n-level certificate hierarchy)
For initial registration with the doorman, you'd need to create a CSR request and send it to the doorman, the doorman will then return you the requestId, Using the provided requestId you'll ask the doorman if the CSR has been signed by him or not once done, Doorman will hand you over the node certificate like below
Once you've the node certificate signed by the doorman, you want to validate it (for this you'd need the RootCA Certificate which is inside the network-root-truststore.jks now you don't need it to create the CSR, but the certificate received must be validated, as result, you need this. Also, this prevents man in the middle attack.)and generate the TLS key pair and certificates.
The above process is automatically done by the corda node for you at the time of initial registration when you start the node using this command -> java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
One Important thing is you should remove or delete the network-root-truststore.jks file once you are done with the registration.
I have some questions about Corda Network Permission. In creating a root network CA's keystore and truststore section in https://docs.corda.net/releases/release-V3.1/permissioning.html#id6
Create a new keypair
This will be used as the root network CA’s keypair
Create a self-signed certificate for the keypair. The basic constraints extension must be set to true
This will be used as the root network CA’s certificate
Create a new keystore and store the root network CA’s keypair and certificate in it for later use
This keystore will be used by the root network CA to sign the doorman CA’s certificate
Create a new Java keystore named truststore.jks and store the root network CA’s certificate in it using the alias cordarootca
This keystore must then be provisioned to the individual nodes later so they can store it in their certificates folder.
I have three questions:
First question is that what is "The basic constraints extension" in your Step 2 means? Due to the code to generate the selfsignedCA is X509Utilities.createSelfSignedCACertificate(subject, caKey) and so I don't know where I can config this parameter.
Second one is that what is difference between " keystore" in Step 3 and "Java keystore" in Step 4? That means the first is "PEM" file and the second is "jks" file?
The last one is that I don't see any parameter about "alias" in Step 4.
By the way, you can give me some useful code to address those problems?
In our Network certificate hierarchy, A Corda network has three types of certificate authorities (CAs):
The root network CA
The doorman CA
Each node also serves as its own CA
The required key pairs and certificates take the form of the following Java-style keystores (this may change in future to support PKCS#12 keystores) in the node’s /certificates/ folder
You can refer to the diagram for hierarchical explanation,
Or you can find more information at: https://docs.corda.net/docs/corda-enterprise/4.4/network/permissioning.html#key-pair-and-certificate-formats
I am using jpasskit to generate and sign passes. So, I created a signature file from a sample manifest.json, using my p12 file and the Apple WWDRCA certificate. Then I decided to do the same thing (using the same manifest and certificates) using this Objective C code. But the signature files are different from each other.
I suspect there is something wrong with the jpasskit code. So, is there any way to decrypt the signature or otherwise inspect them somehow to see what is wrong?
Looking at your pass signature (provide in chat), it looks like you are using an Apple Production IOS Push Services certificate (com.paguemob.mobileios.PagueMob) to sign your pass.
You need to be signing with a Pass Type ID certificate, and that certificate must match the name of the certificate you have in your pass.json (pass.com.paguemob.mobileios.PagueMobS).