I have set up a hyperledger rest server using HTTPS and TLS. I'm wondering why my browser says the connection is not secure though. See images below:
Connection not secure
Root certificate not trusted
Do you have to make your own certificates so that they are trusted, or does anyone have any info on how to fix this?
Where did you get your certificates from? If you did not request and obtain them from a trusted CA then this is expected behaviour on a typical Dev environment. (Perhaps you just used the default certificates from Composer.)
In a production scenario you would request and use certificates that you had obtained (purchased probably) from your organisations usual CA.
This is not a Composer specific problem, but a general HTTP feature.
Related
I am trying to securing the service calls that are made from my node to other services secure. All the other services have enabled https. I tried the following methods
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'
which as per my understanding ignores all error so removed from the code becuase of certificates
I am using request module. where we can configure
key - provided my private key file,
cert - provided my certificate file
ca - certificate authorty chain
then it was throwing UNABLE_TO_VERIFY_LEAF_SIGNATURE
I found out that node doesn't read ca from the system.
it has its own ca chain So I included node-ssl-root-cas
which fetched latest cas from internet.
Then using ssl-analyser, i was able to find my domain doesn't have intermediate ca certificate
I downloaded that from our ca and made a ca chain and attached it to ssl-root-cas
Then i was able to make requests successfully
But Even if I remove key and cert from my request i am able to make request and get result.
How can I check my request and response are actually encrypted?
Or node just ignoring errors,
FYI, Node will use the certificate auhtorities installed on the system if you don't provide your own with the "ca" property. When you do provide your own, the system ones are ignored. This is by design, as providing your own CA likely means that you want to only trust certificates signed by your own CA. If you aren't using your own CA, you can skip setting the "ca" property. If you are, then I'm not sure why you would need to provide the full list of commonly trusted CAs as well. That seems like a pretty odd use case.
You can use the https module to make requests without providing your own key and cert. This is expected and documented behaviour. For technical reasons, when making any https requests, more specifically opening any TLS socket, the client also needs to have a private key and certificate. In the default case, the server doesn't verify the client in any way, so browsers use what's commonly referred to as a "snakeoil" certificate - a bundled self signed certificate.
The use case for providing your own key and cert when performing https requests, is when the server has client certificate checks enabled. For example, when connecting to Apple's servers for delivering push messages to iOS, you have a client certificate issued by Apple that Apple's servers uses to verify that you have access to send push messages (the certificate was issued by Apple) and which app you are sending to (the fingerprint/checksum of the certificate).
Unless the https services you talk to require specific client certificates, you're better off not setting "key" and "cert" - there's no real reason to do that.
So, in summary, you can probably skip setting all three of key, cert and ca, as the real problem seemed to be your mis-configured server (it didn't serve the CA chain).
I have website hosted on IIS. My main issue is that I want only users with a specific certificate installed to be able to access the site. I tried to follow some tutorials but I can't find anyone covering both server and client side, since I can't get it to work.
I have some questions to the main issue:
What kind of certificate should I use (domain/selfed signed in IIS 7.5)? I do have access to a Active Directory Certificate Services where I can create other types of certificates (CA), but the problem is when trying to import them to my IIS ("certificate cannot be used as an ssl server certificate")
I would like to use a CA certificate, but is that possible when using IIS? Or do I need to write all the code the check if the user has the right certificate?
When created a certificate for the website (e.g. though IIS)..How do I create user certificates that are trusted by the server certificate?
As you may noticed by now I'm not sure how to do all of this, and would really like some help..
Server should use SSL server certificate. This certificate has to have Server Authentication extension in Extended key usage. Server certificate should have SAN extension (Subject alternative name) with domain name of server as DNS name (i.e. somesite.com)
CA certificate has to be imported to Trusted root store (preferably Local Machine) on both server and client machines.
Client certificate should contain Client Authentication extension in Extended key usage.
All EndEntity (client and server) certificates should have CRL distribution point in them where there is URL to CRL that is issued by CA. CRL has to be accessible by both client and server and should be always valid.
You can use XCA for training purposes. It has a nice GUI and it has templates for CA, SSL server and SSL client certificates by default. Then you can mimic these certificates in your Active Directory Certificate Services. Documentation and some guides can be found here.
I get the following error message.
You have asked Firefox to connect securely to www.gstatic.com, but we can't confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.
www.gstatic.com uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
(Error code: sec_error_unknown_issuer)
Can someone please help me to solve this issue :'(
You're receiving this error message because the certificate for the site isn't valid. In order to communicate using SSL with a site, the site must provide a valid certificate. There are a number of things necessary for a valid certificate, but one factor is the certificate must be issued by a trusted certificate authority, or CA. Your browser is preconfigured with a set of trusted CAs, but for this particular site, the issuer is not part of that set of trusted authorities.
Furthermore, since the site is using HSTS (HTTP Strict Transport Security), an exception cannot be made for this certificate.
You'll need to view the certificate and see who issued the certificate (the CA) and whether that is a real CA. The certificate may be self-signed, which means the site issued their own certificate without a trusted CA. If you wish to continue, you'll have to install the issuer's certificate as a trusted CA in your browser. However, do not install the issuer's certificate if you cannot verify their identity as a trusted CA.
This article on your particular error may provide guidance on why you're seeing this message. Here's a general description on how SSL works and what roles certificates and CAs play.
With regard to the first solution, if you end up having to install a CA cert into your Firefox browser, click Edit Trust and check the "This certificate can identify websites" checkbox. If that checkbox is not checked, then Firefox will still not trust websites who issue certificates signed by that CA.
My company has external web api service and I want to make it secure using SSL certificate. This service is called by internal application only. Is it secure to use self-signed certiifcate in IIS on production?
Yes it is secure to use a self-signed certificate even.though it is not best practice for Production environment.
Indeed the Root CA will be unknown and the client cannot validate the issuer. Your client will have to accept such a certificate (this means you will have to handle the certification check yourself)
How to ignore the certificate check when ssl
If the API is used only internally, it is not a big deal. If you have some external consumers, you should really just go and buy a certificate.
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.