Deno: Flag to Override "Bad" SSL Certificates

[Lonniebiz]

deno 1.0.0
v8 8.4.300
typescript 3.9.2

In Deno, is there already a way to override the pedantic scrutiny that often causes self-signed SSL certificates to be deemed "Bad Certificates"?

It seems that Deno security is so high that it blocks self-signed SSL certificates for vague reasons.

Not all SSL certificates should be subjected to international banking standards. There are valid reasons for creating self-signed SSL certificates with (practically) never expiring expiration dates. Too many security zealots automatically frown upon self-signed certificates, but hear me out.

Let's say you have two servers on a LAN, that serve each other with separate APIs. And, the only security you want, is to have encrypted data transfer between those two servers and nothing else. And, let's say these services (that these two servers provide) do NOT require internet to function.

Let me ask you this. Why the hell would you want to authenticate the SSL certificate with a 3rd party internet resource? The internet itself now becomes an unneeded external dependency that could potentially bring your service to a halt if the internet goes down (for a service that otherwise needs zero internet).

Well that's exactly what can happen, if deno has no way to override errors like this:

The above script and certificates are zipped here: testDeno.zip

The ssl certificates were generated with a command like this:
openssl req -nodes -new -x509 -keyout private.key -out server.cert -days 1825000 -subj "/C=US/ST=Texas/L=Houston/O=ChickenPeck Technologies/OU=Org/CN=localhost"

I suspect the certificate is bad due to the extremely far off date to which it expires. It would be nice if the error went into more detail about the exact reason the certificate is a "bad certificate".

However, even if that is the reason, I'd like the ability to override and ignore such pedantic scrutiny. I'm not going to use something that inconveniences me with a mandatory security level that is beyond what I want it to be.

Also, why would you want to schedule, on your calendar, a date (one year from now) when your service will crash due to an expired certificate? Instead, I want the service I created to live on without interruption, without any certificate update maintenance, until I decide I want to update it. As the developer of these services, I should be able to prioritize "uninterruptible" over "unnecessarily secure".

Is there already a way to override these type of certificate rejections? If not, I'm requesting it.

[Caesar2011]

Continue to talk in issue #5260 . Consider to close this issue because of being a duplicate. :)

[kitsonk]

Yeah it is duplicate of #5260.

[Lonniebiz]

Isn't the focus of this issue slightly different than #5260?

My focus here is not to merely catch the exception or make the error message more specific about the exact reason for the rejected certificate. To me, it seems that catching an error like this (alone) doesn't necessarily mean you'd be able to override it to the point that Deno would consume the "bad certificate".

My main aim here, is to allow the developer to decide if Deno's reason for the certificate rejection is valid for the developer's use-case, and if it isn't, give the developer the ability to force Deno to use what Deno considers to be a "Bad Certificate".

For example, if the certificate is a "Bad Certificate" because it has an expiration date too far in the future, or because it is self-signed, or because it cannot be authenticated by a 3rd party internet resource, or because it has expired: Those are reasons that the developer should be able to preemptively make deno ignore, so that no exception even occurs. That's different from #5260.

To me, even though this issue is related to #5260, it seems to focus on priorities that would remain an issue even after #5260 is fixed.

[kitsonk]

A "Bad Certificate" is not a subjective thing that is left up to some code running on the server. It is something is part of the security toolchain of the local host. I agree it is worth investigating how to get self signed certificates working, but it isn't something that should be decided in runtime JavaScript code.

[Lonniebiz]

I disagree. A "Bad Certificate" is indeed a very subjective thing when it comes to runtime-javascript. Especially when you consider some of the reasons that a certificate is deemed bad:

subjective #1: A certificate is bad if it has an expiration date greater than one year.

subjective #2: A certificate is bad if it has expired (and this should halt a running service).

subjective #3: A certificate is bad if it is self-signed.

subjective #4: A certificate is bad if it cannot be authenticated by a 3rd party internet resource.

As a developer, who doesn't want any of those reasons to halt my HTTPS services. I find those reasons to be very subjective and I do indeed want to override them with server-side javascript at runtime.

And by the way, in Node.js, I'm able to run the very same certificates, that are being rejected by deno, to achieve uninterrupted services.

I'm also able to ignore bad certificates during fetch operations using an agent in node-fetch:
const httpsAgent = new https.Agent({ keepAlive: true, rejectUnauthorized: false });

The 1.0 Deno Release is just a toy to me, until I can do these same things in deno.

[bertvanbrakel]

I agree. I'm using self signed certs in local/dev/test, on a kubernetes cluster where the certs are generated at runtime, specific to the developers machine. I have my own self signed certs I want to use for that purpose.

My issue is on the consuming client side for now. Surely a callback handler where one can return a true/false whether to accept a cert would do? And maybe log a warning to the logs about it (so it's very obvious)

[Cretezy]

Facing this same issue while trying to write tests for a server. I'm using a self-signed certificate. It would be nice to have some sort of flag along side certFile to allow self-signed certs for these purposes (maybe named insecureAllowBadCertificates or something that conveys that this can be insecure)

[callionica]

I'm trying to write a client that consumes the Philips Hue API from Signify (a home automation API for controlling lighting). The API is accessed over https to hardware (the "Hue bridge") running on the local network. The Hue bridge uses a self-signed certificate. I've got no control over the certificate the bridge uses. Deno already can't handle sending requests to IP addresses, but Deno also doesn't like the self-signed cert.

I get this error when making a request to a Hue bridge using its host name:

Sending fatal alert BadCertificate
error: Uncaught (in promise) Error: error sending request for url (https://.../): error trying to connect: invalid certificate: UnknownIssuer 

I can get a web browser to accept the self-signed certificate (with some guidance to the user), but apparently I can't get Deno to accept it, so this is another vote to get fetch requests to servers that use self-signed certificates working in Deno.