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
Related
There are 2 nfs shares on our linux redhat servers to host the live and landing data. There is keytab refreshed ( ticket produced) every 30 minutes , apparently it give system account an access to those 2 shared drives. If key tab ticket is not valid then i guess we would get key is expired error on browsing those 2 nfs locations.
This is what documented as a part of handover from other team. I don't have test env and I got to replace the keytab from rc4 to aes but my problem is that I don't know how keytab is associated with those 2 locations? . It seems it encrypts the locations and allow the access to them with keytab only.
Do I need to change any conf file to replace keytab from rc4 to aes. Kerb cong has already got entry to allow new encryption types aes128.
Unix , nfs storage and ad teams are not giving me answer and i am new to all of this. I have read online that there is sssd.conf file that could be used in conjunction with kerb conf . Can you give me direction from your experience
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 want to create a new Node for my corda network. Can you help me with correct steps for generating a proper Certificate Key for a new node in non-dev Mode.
When adding a new node for an existing non-dev network, you need to register with the network's certificate signing authority (or doorman) to obtain a valid identity for the zone using the following command:
java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
As part of this process, the node will automatically generate a new public/private keypair. You do not need to generate this keypair yourself.
Before you can register, you must first have received the trust store file containing the root certificate from the zone operator. By default the trust store file is expected to be in the location certificates/network-root-truststore.jks. This can be overridden with the additional --network-root-truststore flag.
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.
Is it possible to give asp.net read permission to the certificate store?
If yes , how?
If no... do I need to set the permission manually per certificate file?
If yes where are these files physically on the HDD?
Generally you give permissions to A certificate. I use a method like this to find the custom made cert and grant permissions. If you are using a cert issued by a public entity like Verisign, Thawte, etc, this is probably unnecessary.
FindPrivateKey.exe My LocalMachine –n "CN=<certificate issuer>"
...will find certificates on the local machine in the personal store for a particular issuer.
Note: If FindPrivateKey is not on your local machine,
download the WCF samples, including the FindPrivateKey tool, at
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21459
FindPrivateKey returns the location of the private key for the certificate, similar to
"C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030".
Run the following command line to assign read only access permissions to the process identity of the ASP.NET/WCF Service
cacls.exe "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030" /E /G "NT AUTHORITY\NETWORK SERVICE":R
NOTE: If you are running Microsoft Windows® XP, give the certificate permissions for the ASPNET identity instead of the NT Authority\Network Service identity, because the IIS process runs under the ASPNET account in Windows XP.
Certificates are viewable from the MMC snap in for Certificates. Open MMC, choose File --> Add/Remove Snap in, click the add button and choose certificates. From here you will need to choose the appropriate store (usually Computer Account - Local Computer for ASP.NET items) to manage and then you can view/admin the certs.
Please take a good hard look at the different command line options, and make sure that you have a clear understanding of what certificates are and how they work before granting any permissions.
The network service account that asp.net run under by default doesn't have access to the local machine personal certificates. Grant access by the following:
Repost from Sohnee # forums.asp.net
Step 1 - if you don't already have it
installed - get WinHttpCertCfg
Step 2 - if you already have the
certificate installed on the machine
and you just need to grant access to
Network Services:
WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "IssuedToName" -a "NetworkService"
Don't really like answering my own questions, but one simple way to get rid of this error is just to give network service full access to the c:\drive, and propagate permissions down.
You'll shoot me down I know, telling me how bad this is - but it works.