what usually CA certificate look like? Does it contain the server’ public Key or what it use to prove the cerfiticate(digital signature) from server sending?
Any certificate contains a public key, which is paired to a private key contained in a private portion of the certificate (i.e., the part that the server has installed but does not distribute to clients). This is independent of whether the certificate belongs to a CA or not.
The digital signature will typically belong to a certificate further up in the chain of trust (i.e., the certificate's issuing authority), but if you're looking at a root certificate, it may be self-signed, as those entities are trusted to sign any certificates, even their own.
If you want to look at the contents of any certificate, your browser will let you do that on any HTTPS-based website you visit, typically by clicking somewhere in the address bar. You can search for specific instructions for viewing certificates in just about any major browser. This will let you look at the certificates all throughout the chain of trust, up to the root CA.
Related
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
Why is there a SMTP/HTTP Protocol? I mean, why can't we use (or extend) the existing SSH protocol? Wouldn't using SSH also eliminate the need for a paid key?
Or, perhaps another why to frame this question is why do we need yet another encryption scheme?
There are different protocols for different purposes. What I'm hearing here really is 'why do we need to pay for an SSL certificate in HTTPS but not SSH'.
The reason for this is as follows:
When you first connect to a SSH server, you as the person logging in are asked to validate the public key. Do you read it and recognize the code before you accept it?
Imagine if this were needed the first time you connect to any HTTPS server. We can't ask users to validate every public key manually. How would they recognize what a public key is the correct one?
We solve this by relying on other authorities to validate the keys. These authorities don't just sell SSL certificate, their product really is validating that the person owning the domain is the one encrypting it.
So you can totally generate your own self-signed SSL certificates, but browsers won't recognize these by default. Browsers and operating system have a database of certificates they trust.
Anyway, these days you no longer need to pay for a certificate. LetsEncrypt gives them away for free.
I am trying to set up smart card authentication for a website that I have created. Setting authentication to Windows and setting SSL to required I can get the smart card reader to pop up when they go to the web site. There are 2 credentials on the card though and only one of them is showing up as an option (the information I need is on the other credential). I asked a co worker and he said in IIS 6 there was a way to specify a location on the smart card to look for certificates. I have been researching this issue for about a week now but haven't been able to find a solution to this issue yet. Does anyone know how to do this?
IIS really only knows about certificate-based authentication, not smart-cards per se (which is really just a form of cert-based authentication). Configure your site to use certificate-based authentication, eg "Require Client Certificates" and IIS will chain the call down to Windows security, which, in turn, recognizes that among the sources for identity certificates is the smartcard reader. Depending upon your site requirements, you may also need to enable Certificate Mapping, which translates certificates into Windows account identities.
When certificates are required (or accepted) IIS will ask for a client cert in the SSL negotiation when the session is started. IIS will send a list of the Certificate Authorities it trusts to the client. The client then takes those and sees which match the list of Certificate Authorities it trusts. It then take sthe list of common entries and checks to see if it has any certs issued by a CA both sides trust. Generally, if there are none it will simply not send a cert and the request fails if the cert is required. If there is just one certificate IE will generally send that without asking the client which cert to send, but it will prompt for a PIN if required. Finally, if there are more than one certificate issued by a CA both sides trust then a dialog box will be presented to the client asking which cert to use.
In this case it sounds like perhaps the credential (certificate) you want the client to send is issued by a Certificate Authority that isn't trusted by one or both sides.
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 could not find a link that describes Domain certificate, I am familiar with SSL certificates, and certificate authority but I don't know about Domain certificate.
and what is Multi-Domain certificate.
thanks
From the description in some CAs (e.g. Comodo), a multi-domain certificate seems to be a certificate that can be used with multiple host names: this is done by putting multiple subject alternative name entries in the certificate. This is useful if your server has multiple hosts on the same IP address (but does not support server name indication (SNI) which is not widespread yet). In this case, only one certificate may be used for all the hosts sharing the same IP address (before HTTP has a chance to say to which particular host it wants to talk to), so this certificate has to be valid for all the hosts on that server (with same IP address and port).
That's not the same as a wildcard certificate, which contains a single name, but with a wildcard to represent a pattern in the name.
"Domain certificate" certainly depends on the context, but it could either be a "single domain" certificate (as opposed to a multi-domain certificate), or, in the context of Microsoft IIS:
[...] an internal certificate that does not
have to be issued by an external
certification authority (CA).
I Open IIS7 and tried to create a domain certificate, it seems just a certificate issued from CA.