How can the certificates inside a Corda network be signed by Certificate Authority? Is there a defined process for managing the certificates for each Node and participants in Corda network?
To join a Corda network a Node needs to obtain a certificate from the Identity Manager of the network they want to connect to. It is described in the documentation of Corda Enterprise:
To connect to a compatibility zone you need to register with its
certificate signing authority (or doorman) by submitting a certificate
signing request (CSR) to obtain a valid identity for the zone. This
process is only necessary when the node connects to the network for
the first time, or when the certificate expires. You could do this out
of band, for instance via email or a web form, but there’s also a
simple request/response utility built into the node.
Before using this utility, you must first have received the trust
store file containing the root certificate from the zone operator. For
high security zones, this might be delivered physically.
So, first the node operator needs to get in touch with the network operator offline and provide its X.509 information. The network operator will provide the node with:
truststore.jks, the network/zone operator’s root certificate in keystore with a locally configurable password as protection against
certain attacks
At this point the node can then use the node utilities to make a CSR (Certificate Signing Request) to the Identity Manager to obtain the node certificate and receive the following:
nodekeystore.jks, which stores the node’s identity key pairs and certificates
Note that this can be also provided directly by the network operatort, I guess it depends on their policy. It is also described in the documentation.
The node can also create its own sslkeystore.jks,
which stores the node’s TLS key pair and certificate
that can be used, for example, to connect an external RPC client to the node.
The node certificate expires and can be revoked by the Identity Manager, so in that case it needs to make other specific request to obtain a new certificate.
Further readings:
https://docs.corda.net/docs/corda-enterprise/4.8/network/permissioning.html
https://docs.corda.net/docs/cenm/1.5/pki-guide.html#certificate-hierarchy-guide
Related
Hope someone can help me on this.
My understanding from Corda docs is that Corda network is a semi-private. Seems to me that everyone sends a CSR with required information (legalname & emailaddress as in Corda example) to the doorman (there is limited detail about the doorman, but I know that Corda will provide one), will then get certificates and access to the network.
My Questions:
If I want to fully control who (the node) can access to the network,
do I need to build my own doorman service?
Will the doorman also act as an intermediate CA to sign the certificates?
Regards,
Kwan
The Doorman in Corda network receives Certificate Signing Request and distribute signed certificate once the CSR has been approved. All the certificates issued by the doorman will have the same root certificate, thats what enables nodes to connect to each other to form a Corda network.
So, you don't really need a doorman if you want control on who have access to the network, you only need to make sure you are the one controlling the root CA/intermediate CA, you can create the certificate for each node manually using any key tools or by using Corda's X509Utilities (which uses Bouncy Castle). You can look at ConfigUtilities.createKeystoreForCordaNode for how to create a valid keystore for Corda node.
For the second question, in non-production network the doorman can act as the intermediate CA, but it should be done by Hardware Security Module (HSM) in production network.
I have a WCF-BasicHTTP send port configuredas follows:
Security tab Security mode:Transport;
Transport client credential type: Certificate;
Client certificate: (thumbprint of our client cert);
Service certificate: (thumbprint of the service's public key cert).
General tab, Endpoint Identity: everything is left blank.
There is a send pipeline component that substitutes alternative endpoint addresses depending on the interaction type (all endpoints share the same base URL).
Recently, our trading partner has renewed their server certificate, and failed to notify us in advance. The send port continues working (good). However, the behaviour leads me to believe that even though BizTalk forced me to specify some service certificate thumbprint, the adapter then does not actually verify the service certificate thumbprint against what's set in the binding. I can't figure out if this is a bug or by design?
Issues have been asked many times about how to handle self-signed certificates with Java and implementations are often provided. However, I'm not sure that these implementations will give me the security/trust I am looking for.
My circumstance is as follows: I have a client program connecting to our server application. Both of these we have complete control over. Our client post's a stream using https to a URL at our server, and the server responds. Currently (and this is what I'm trying to fix) the server has a self signed certificate. Java doesn't like this and FOR TESTING ONLY, we are pretty much ignoring the certificate altogether by trusting any certificate.
I have little knowledge of SSL. My boss says we can use our self-signed certificate and it will be secure as long we don't make our crypt. key public. This sounds correct to me, but a lot of posts say self-signed cert's are automatically vulnerable to man-in-the-middle attacks. Does this mean SSL sends the crypt. key along with the certificate?
Since we have control over both ends, should we just encrypt our data ourselves with a secret key, and decrypt it at the end using our key? Or is there reason to use SSL?
Instead of trusting any certificate blindly (which would make the connection vulnerable to MITM attacks), configure your Java client to trust that particular certificate. Self-signed certificates do not inherently make SSL/TLS connections vulnerable to MITM attacks, they just make their distribution and the evaluation of trust more specific to this particular deployment (i.e. you have to configure it manually).
You can do this in at least 3 ways (pick the easiest one for you, I'd suggest bullet point #2):
Import the server certificate into your client's global trust store (lib/security/cacerts in your JRE directory). This will make all applications run with this JRE trust this certificate.
Import the server certificate into another truststore (possibly a local copy of lib/security/cacerts) and make this particular application use this truststore. This can be done using the javax.net.ssl.trustStore system properties.
Make your client application use an SSLContext initialised with an X509TrustManager configured to trust that certificate: either something written manually or a trust manager coming from TrustManagerFactory initialised by loading a local keystore that contains that particular certificate (as in the previous method).
You'll find more details about all this in the JSSE Reference Guide.
(This answer to a similar question should give you the details for doing all this properly, in particular keytool -import ....)
The arguments against self signed certificates mainly apply to web-applications. Since with the current infrastructure a browser won't be able to validate your self-signed certificate.
Since you have control over the client, you can simply hardcode the certificate you expect into the client. For example you might calculate the sha1 hash of the certificate, and check if that matches the expected value. That way you don't even need to trust hundreds of CAs.
To achieve secure communication you need to first ensure your talking to the right computer. When the client first attempts to establish a secure connection, it pings the server and the server responds with its cert. At this point you MUST validate the servers cert before continuing. The cert includes a public key and signature that can be used to ensure the cert is valid. For example, in web browsers this means checking to see it's been signed by an authority listed as trusted in your browser settings, if that check fails you'll see red warnings in your browser. In your case this will mean you have manually (or in code) added the servers cert into a trust store so that it is trusted.
I want to send a request to HTTPS adapter through BizTalk server 2009. My BizTalk adapter is dynamic and it's takes configuration details from database instead of directly mentioning it on server.
I have installed X509 certificate in my browser and imported it in MMC.
I am getting following error in my BizTalk
A message sent to adapter "HTTP" on send port "sndHL7" with URI "https://xxxxxxxxx/imm/test (https://xxxxxxxxxxxxx/imm/test)" is suspended.
Error details: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel
I searched for this error, but every where I got following response only :
Error: – Details: “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Solution: The error message normally occurs if the client certificate is not configured correctly. You should check that you have configured your client certificate in certificate store under BizTalk service account that hosts the HTTP adapter.
I am not getting how to configure that certificate in proper certificate store. I have 3 files wih extension .cer, .cer and .pfx. The file with extension .pfx requires password to install it in any store.
Also, how to configure certificate under BizTalk service Account? Should I select "Service Account" while adding snap in in MMC and then select BizTalk service from the list of services.
I don't know about biztalk but if you are presenting a cert you need the associated private key. A cert is like a photo ID. It is hard to forge, but it still doesn't prove your identity unless you can present your face for someone to compare with the ID. Assuming the file extensions match the actual format of the files, the cer files are either DER, BER or PEM encoded certificates without the private key. So you need the pfx file. So if the proposed solution from the error message is correct, you need to find that password and install the certificate and private key from the PFX file into the store.
The two .cer files must be the root authority and server certificates and you must trust them.so you need to place them in your LOCAL MACHINE- Trusted Root Certification store. (use MMC)
Now the .pfx file will have the client authentication certificate that you will be passing into get authenticated. Import this certificate to LOCAL MACHINE,Personal (or MY certificate store if using command line) check private key as exportable.
Now allow BizTalk service account access to the private key of this certificate.
MMC use add snap in and add local machine.
select the client certificate in Personal right click- AllTasks- Manage private keys. Now add your BizTalk service account as a user and give access.
Or else use winhttpcertcfg tool in command line
Im implementing my own RPC framework and well moste of the stuff is done but i need some help how do i verify a auth_unix? the structure of the data is definied in http://www.faqs.org/rfcs/rfc1050.html 9.2 UNIX Authentication but how should i verify the user?
UID and GID are compared to the UID and GID on the server to validate their authenticity. These IDs can be shared across unix systems using NIS or some other facility. Anything subsequently executed on the remote system is run under that effective UID and GID.
The application behind the server may implement further authentication, but note that AUTH_UNIX does not authenticate the user in itself; it trusts the UID and GID supplied.
From Section 9.3:
9.3 DES Authentication
UNIX authentication suffers from two major problems:
(1) The naming is too UNIX oriented.
(2) There is no verifier, so credentials can easily be faked.
DES authentication attempts to fix these two problems.
If you use Unix authentication you can only assume that the message originates from a trusted host and some mechanism was in place to authenticate the user before they got the chance to do something that originated the call.
In this case it would be up to the application to verify user credentials. The originating machine name is also supplied so you could make sure that the originating IP address matches it and only reply to that address - this has obvious vulnerabilities to DNS cache poisoning attacks. Also, making this play nicely with DHCP or NAT is left as an exercise to the reader ;-}
Which means you have little choice but to trust the UID and GID or do additional verification within the application sitting on top of your RPC library. The RFC discusses more secure authentication mechanisms. However, Sun RPC is not the most secure of protocols and is generally not recommended for services provided to untrusted clients.