Develop Reference

how can I force fetch to accept a self-signed certificate in a web app front end?

I am prototyping a simple web app front end that needs to fetch JSON data from my server. The server itself works fine -- I can click on the link, and the JSON data shows up in the browser. But the following simple script fails:
fetch('https://x.x.x.x:8000') // MY URL FAILS
// fetch('https://jsonplaceholder.typicode.com/todos/1') // ALTERNATE URL WORKS
.then(function() {
alert("Successful")
})
.catch(function() {
alert("Failure")
});
I'm completely new to this sort of front-end work (and to Javascript in general), so I might be overlooking an obvious reason, but the two that come to mind are
my server uses a self-signed certificate for testing purpose; and/or
I'm using a non-standard port.
The first of these possible explanations seems more likely.
Accessing the web page generates a bunch of errors, none of which mean anything to me (except for not finding the favicon):
I will temporarily post the full URL in a comment below, in case anyone else wants to see what happens, but I would delete it once a working solution is suggested.

To answer your question as asked, no, you definitely can't use fetch to force the client (browser) to ignore cert errors. Especially in cross-origin requests (and going from one port to another is cross-origin), that would be a HUGE security hole. It would allow anybody who could get a man-in-the-middle position on a victim's network (not hard) to steal information from the victim's HTTPS connections using fraudulent certificates to intercept the HTTPS requests and responses.
You might be able to force server-side JS (in Node or similar) to ignore cert validation errors, since in that case you (hopefully!) control the code the server is running. But it doesn't look like that's what you're doing, and in a web page, somebody else (the server owner) controls what code you (the browser) are running, so you definitely can't let that code turn off important security features!
Attack scenario for if JS could turn off cert validation:
Suppose you and I both control web servers. I, a malicious attacker, would like to intercept the traffic between your users and your web server. I even have a man-in-the-middle (MitM) network position on some of your users! However, you are of course using TLS (via HTTPS), so I can't decrypt or modify the traffic.
However, your users sometimes connect to my server as well, not knowing it is malicious (maybe I mostly use it to serve relatively innocuous stuff, like a comment system or analytics tools, so lots of sites embed my scripts). My server can tell when a browser requests content from an IP address where I could launch an MitM attack, and serve them malicious scripts.
Now, in the real world, this doesn't matter! Sites don't trust other sites, because of the Same-Origin Policy, a critical browser security feature. My site (or the scripts I serve) can cause your users to submit requests to any other server that I choose, but they can't read the responses (if the other server is cross-origin), and they can't turn off certificate validation so my MitM position is mostly useless.
However, suppose that there was a way - as you propose - for scripts to tell the browser "it's ok, just trust this one particular self-signed cert when making this request". This changes everything. My MitM host will generate a self-signed cert (and corresponding private key) for your site, and send the cert to my own web server. When a potential victim loads a script from me, it only only contains instructions to make HTTP requests to your site, it also specifies that the browser should trust the self-signed certificate that my MitM node generated.
The victim's browser would then start the request, attempting to establish a TLS connection to your server. My MitM node would intercept the request, and reply with its self-signed certificate. Normally the browser would reject that, but in this case it doesn't because you created a way to tell browsers to accept a particular self-signed cert. Therefore, the victim's browser trusts my self-signed certificate. The actual request never even makes it to your server. The victim's browser, believing itself to be interacting with the legitimate server (yours) rather than with my MitM host, sends an HTTP request containing secrets such as cookies and/or API keys / bearer tokens / login credentials / etc. My MitM intercepts that (as it's intercepting all traffic), decrypts it (because it is in fact one end of the TLS tunnel, this is trivial), and can access the victim's account on your server. (My MitM host can also duplicate the responses from your server that the victim would usually see, to keep them unsuspecting. The MitM host can even tamper with this responses, if I want it to mislead the user.)
The usual way to solve this is to install the server's certificate as trusted in the browser (or in the OS). That way, the browser will recognize the certificate's issuer (itself) as valid, and consider the certificate valid.
What happens if you go to https://x.x.x.x:8000/ in the browser directly? If you get a certificate error, well, that's your problem: the browser doesn't trust the certificate of the server hosted on that port. You should have an opportunity to temporarily or permanently trust that certificate (exact details will depend on the browser).
Note that, of course, doing this on your own computer won't fix it for anybody else's computer. They'd need to manually trust your certificate too.
The actual solution is, of course, to install a trusted certificate. Perhaps you should try Let's Encrypt or similar, for a nice free cert that every client will trust without extra shenanigans?

Just had the same problem and stumbled upon the solution by accident. It is possible by just making the user open the self-signed site, click on 'Show more' and 'Accept the risk and continue'. After doing that, fetch requests go through like nothing ever went wrong.
It works on Firefox:
and Chrome:
This method just has the caveat that you have to do the setup, and on Chrome it displays 'Not secure' even when the rest of the page is secure.
But if you need HTTPS locally, this works like a charm. Hope this helps the people who came here from Google :)
EDIT:
Also worth mentioning, I tested it on localhost but it works everywhere.

Detect on the server-side if a client rejects my TLS certificate

I'm building an HTTP proxy in Node.js, which attempts to intercept HTTPS connections, using a self-signed certificate. I'm using a bare http.Server, instantiating my own tls.TLSSocket to upgrade sockets as required, and the functionality all works great when the CA is trusted by the client.
If the client isn't configured with the CA though, it obviously rejects the connection, complaining that there's a self-signed certificate in the chain.
That's all as it should be, but I'd like a way to detect that this has happened from the server-side, so I can prompt the user to correctly configure their client.
Is it possible to do this? It seems the TLS RFC (https://www.rfc-editor.org/rfc/rfc5246#section-7.2.2) has quite a few error alert messages about certificate rejections, which I would expect to cover this, but I can't see to see any debug info in Node about those even with NODE_DEBUG=tls.
Really I'd like to subscribe to TLS error alert events, so I can react to the various interesting cases in there directly. How can I do that?

Usually all what you see is that the client closes the connection. Some clients might send an alert, others don't - the exact behavior depends on the TLS stack. Anyway, you could not redirect the client from within this dead connection anyway.
What you might try is to have some initial page served with plain HTTP where you include some image or similar from a HTTPS resource using a certificate signed with your CA. With some script you can detect if the client has successfully loaded the image or not and in the latter case you can show your information about needing to install some certificate.

LDAP over TLS with ldap-client in node

I am fairly new to the concept of domains and am trying to implement LDAP over TLS in node. And I have been stuck with this issue for many days now. I am using ldap-client.
var LDAP = require('ldap-client');
var ldap = new LDAP({
validatecert: false, // Verify server certificate
...
}, function(err) {
// connected and ready
});
so with some research I came into conclusion that, if the field validatecert is to be set amount these values
LDAP.LDAP_OPT_X_TLS_NEVER = 0;
LDAP.LDAP_OPT_X_TLS_HARD = 1;
LDAP.LDAP_OPT_X_TLS_DEMAND = 2;
LDAP.LDAP_OPT_X_TLS_ALLOW = 3;
LDAP.LDAP_OPT_X_TLS_TRY = 4;
which was quoted under the section TLS in the library documentation
TLS can be used via the ldaps:// protocol string in the URI attribute on instantiation. If you want to eschew server certificate checking (if you have a self-signed cserver certificate, for example), you can set the verifycert attribute to LDAP.LDAP_OPT_X_TLS_NEVER, or one of the following values:
With which I could setup a secure connection.
I know that we need certificates for TLS connection to work. One is held by the server and another by the client (me).
My question is if I set the field to any of the said methods:
How am I to verify that my connection is secure ?
Where do I see the certificates or not see them at all ?
Do I have to manually generate certificates from the server and use them ?

Certificates are a means to help others verify that the entity presenting the certificate is indeed who it is claiming to be. Thus, when you connect to a server and server returns a certificate, then through that certificate you can be sure that server is indeed the server and not an imposter.
The power of certificate is due to the issuer (also called Certificate Authority or CA). If you trust the issuer, then you effectively trust the certificates issued by it. A list of prominent CAs is usually present in the OS itself, so getting a certificate and verification of that certificate is transparent to the application developer, especially when you are using libraries.
Taking your points one by one:
I know that we need certificates for TLS connection to work. One is held by the server and another by the client (me).
You didn't ask any question here, here is some general info. Usually server verification is all that's needed. In high security environments, client verification is done too and there you (i.e. the client) would need a certificate from a CA to verify yourself to the server. But, in most applications, server verification is sufficient.
It is similar to Normal Forms in RDBMS normalization. Even though you have Normal Forms as strict as 6NF, usually RDBMS's are normalized till 3NF.
How am I to verify that my connection is secure?
Generally, if you are using a well known library, (like curl or openLDAP) calling its secure connection methods is enough. It is very very unlikely that you called a function that the library claims to be secure but it turns out to be a farce.
To be sure though, you can look at your traffic with the server. Wireshark is often used for network traffic analysis.
Where do I see the certificates or not see them at all?
In most cases you don't see the certificates. All you do is tell your library how strict you want the verification to be. And then your library will take care of the rest - often throwing an exception or logging an error if there is some issue with the certificate.
If you are using a client certificate then you would have to keep it on the file system and point your library to it. It is generally a .pem file.
Do I have to manually generate certificates from the server and use them?
No. For server certs, it is the responsibility of the server to provide you with a valid cert. All you have to do is just check that the certificate sent by server is from an established CA - which, as told earlier, is generally a transparent step for the developer using the library.
In cases where you do not care much or in situations where you want to start coding and CA is yet to issue a certificate for you, you can program the server to provide its clients with a self-signed certificate and program the clients to keep the verification less strict.
A self-signed certificate has little value in terms of security. It is like server saying - 'Hey, I'm telling you that I'm the guy you want to talk to.' That clearly isn't enough. You want a third person (i.e. the CA), whom you fully trust, to confirm that that is the guy you wanted to talk to.

Hows is ssl certificate verified and by a browser or server

I've created a self-signed sertificate
$ openssl genrsa -out key.pem 1024
$ openssl req -new -key key.pem -out request.csr
$ openssl x509 -req -in request.csr -signkey key.pem -out cert.pem
and created an HTTPS server:
var server = https.createServer({
key: fs.readFileSync(__dirname + "/key.pem"),
cert: fs.readFileSync(__dirname + "/cert.pem")
}
Then I requested the page. The expected result is that a browser complained that a connection is not secure. My question how does a browser know that? Is it server job to verify the certificate and notify browser about that or it's a browser job?

SSL Certificates are verified by the client.
The server typically will verify the certificate is not broken or corrupt on start-up, but most servers don't actually validate the legitimacy of their certificate.
Why verify the certificate?
Verification of the server certificate is important because otherwise the client can't really know who it is communicating with. MITM (Man In the Middle) attacks can take place where a third party is intercepting both sides of the communication and they can provide their data to you instead of the data from the server which you thought you were receiving.
A little bit about certificate types
Most certificates are signed by CAs, there are also self-signed certificates, and pinned certificates. I advise using a certificate signed by a CA whenever possible. The Second best option (which generally can only be used within an organization) would using your own internal CA and then self-signing your server cert with your CA cert, this is known as a self-signed certificate and it won't be trusted automatically by any clients or browsers which receive it.
In the self-signed option you must import your CA public key into your CA key store for your server certificate to be trusted. Finally there is simply a pinned certificate, this is where you simply tell your browser to trust an otherwise untrusted certificate (do not do this).
Warning - You should avoid pinning certificates because they are almost impossible to replace during a compromise, and certificates should be schedule to expire within a reasonable period, and be regularly rotated. Pinning makes that very difficult if almost impossible in some situations.
Types of certificates
CA Signed (Needed to operate a secure site on the WWW)
Self Signed (Good for internal organization usage, internal company wikis for example)
Pinned (Avoid)
What kind of verification happens?
So you have a certificate, first you configure your server to use that certificate.
Now when a client comes along and requests a secure connection to your site (as indicated by connecting to port 443 in in the case of HTTPS). Your server sends it's public (not private) certificate and begins a secure handshake. One such handshake is called a Diffie–Hellman key exchange. The handshake itself is beyond the scope of this question.
Before participating in the key exchange, the browser will first examine the certificate which the server provided. For it to be valid several checks must be successful.
There are some of the checks performed.
Does this certificate contain the hostname which matches the hostname we connected to?
If NO, does the certificate include a wildcard CN (Common Name)?
If YES, does that CN have a valid "wildcard" that matches the host name we're connected to? YES/NO
Does the certificate include a CRL (Certificate Revocation List)? If so, does that CRL indicate that this certificate is still valid? YES/NO
Is this certificate signed by a known certificate authority (CA)? YES/NO
Only if NO, does this client (browser) have a public certificate (which matches the certificate offered by this server), which has been marked as Trusted? YES/NO *This is also known as a pinned certificate, as you are not relying on a CA to verify it's authenticity.
For the browser to trust the certificate, and by proxy the server. Then we must check each of the Yes boxes above
Other security stuff that makes the world safer
Now there are other things not "specific" to the certificate which are also verified.
For example, both the client and server must agree on the handshake method, the ciphers used, the hashing algorithm used, and other things.
The server may also pass special HTTPS security flags instructing the browser not to trust other certificates for this service for a period of time (this is known as certificate pinning). Certificate pinning like that used in "Strict Transport Security" (not to be confused with pinning a certificate as mentioned above) can help prevent MITM (man in the middle) attacks. This is one of the many extra security features that HTTPS Strict Transport Security offers.
Once all of the security checks have been certified the browser sends any request it had to the server and the server responds appropriately.

When you visit a secured website (with https), the server also sends a certificate signed by an authority to prove its identity (so that you know you're not getting man in the middled).
Then, your browser needs to know if the certificate is genuine or not, because the man in the middle could send a certificate too. Luckily for you, your browser has a list of authorities to trust. If the certificate's authority signature matches one of the trusted authorities, then everything is fine and no alert is raised.
But if no authorities matches, then the browser kindly asks you if we can trust this authority. In the case of a self-signed certificate, you can trust it (but not before verifying the fingerprint, because, again, a man in the middle could send a different certificate to trick you into believing they're the real deal).
If you trust it, then the browser imports it and adds it to the certificates to trust, never raising an alarm again (until your certificates expires or change (like in a man in the middle situation)).

Is it server job to verify the certificate and notify browser about that or it's a browser job?
The main role of the server certificate is to make sure that the client is communicating with the expected server.
If the client (browser) would just trust the server that the certificate is valid some man in the middle attacker could simply claim to be the real server and claim that the certificate is valid. And after this the client would establish the encrypted connection to the attacker instead of the real server which means that the attacker gets access to the sensitive data. Therefore the servers certificate must always be properly checked by the client.
My question how does a browser know that?
In short: by checking that the certificate is trusted by checking the signature of the issuer and following the trust chain up to a locally trusted root certificate, also checking that the hostname of the URL matches the subject of the certificate and that the certificates are still valid, i.e. not expired and not revoked. For more details see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.

JavaScript - GPS position in mobile browser and HTTPS/SSL certificate

I'm running a web app where users can request a map with their position through gps. In order to do that browsers like Chrome and Safari require an HTTPS protocol, not just http, otherwise call to JS function "getCurrentPosition" will fail. (but on Firefox, for example, it's working)
First question: are there any other possibilities to get user location (through gps, not just by ip)?
If not, the only way (I think) is to switch to https.
Now, app is running on a cheap shared hosting (and I can't do anything about that right now), the only thing that I can do is purchase an SSL certificate in order to enable https protocol.
Second question: hosting offers both ssl certificate with dedicated ip and without dedicated ip. Which is the difference? Well, I know what's a dedicated ip, but for my needs (website + this small app) which advantage could I have from a dedicated ip?
Third question: if I choose a certificate from another CA then I need root access to server in order to install it, is it right?
Last one: some hostings offer SSL with identity verification and without it, how theese last work? I mean, https should't guarrantee encrypted connections with a verified website?
If you have any links please post them, most of resources that I found are too old and they don't talk about acquiring gps data with JS.
Thanks a lot!
EDIT: just for completion: this page is about this deprecated js call for non-secure site. Are there other possibilites to get same result?

First question: are there any other possibilities to get user location
(through gps, not just by ip)?
You can track users’ real time location by using Google Maps APIs, I hope below links will help you.
Using Google Map Tracks API
https://developers.google.com/maps/
Second question: hosting offers both ssl certificate with dedicated ip
and without dedicated ip. Which is the difference? Well, I know what's
a dedicated ip, but for my needs (website + this small app) which
advantage could I have from a dedicated ip?
In the past, SSL requires dedicated IP to secure web applications. But in the mean time, SSL doesn’t require dedicated IP due to SNI technology. If your website hosted on shared IP address, then SNI permits a server to implement multiple certificates on a single IP address.
There are plenty of advantages using a dedicated IP instead of shared IP - read this article
Third question: if I choose a certificate from another CA then I need
root access to server in order to install it, is it right?
Whether you continue with current provider or new one, you don’t need root access of server in order install an SSL certificate.
Last one: some hostings offer SSL with identity verification and
without it, how theese last work? I mean, https should't guarrantee
encrypted connections with a verified website?
All SSL certificates are come with industry standard 256 bit encryption and ensures about encrypted connections. There is varying upon their validation process as below.
Domain Validation Certificates - CA will follow automated validation process and confirm only your control over the domain. You will get this certificate in just minutes.
Business Validation Certificates - CA will check your business existence by verifying official documentations. CA will take 2 to 3 business days to issue your certificate.
Extended Validation Certificates - CA will follow strict validation process and validate legal, physical and operational identity of business. EV SSL will enable most visible sign “the company name in the green address bar”, it will increase trust of your website visitors.
I hope this will helpful for you!