Issue 1:
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.

Issue 2:
Because std/http/server.ts uses MuxAsyncIterator to serve up requests, any errors thrown there cannot be caught:

deno/std/http/server.ts

Lines 235 to 239
in
e34a3b6

[Symbol.asyncIterator](): AsyncIterableIterator<ServerRequest> {

const mux: MuxAsyncIterator<ServerRequest> = new MuxAsyncIterator();

mux.add(this.acceptConnAndIterateHttpRequests(mux));

return mux.iterate();

}

The comments on MuxAsyncIterator make it clear that:

deno/std/async/mux_async_iterator.ts

Lines 9 to 14
in
e34a3b6

/** The MuxAsyncIterator class multiplexes multiple async iterators into a

* single stream. It currently makes a few assumptions:

* - The iterators do not throw.

* - The final result (the value returned and not yielded from the iterator)

* does not matter; if there is any, it is discarded.

*/

And in situations where you have a TLS connection where the browser rejects the certificate, you end up with something like this with Deno dumping and no way to recover:

error: Uncaught InvalidData: received corrupt message
at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11)
at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10)
at async TLSListenerImpl.accept ($deno$/tls.ts:31:17)
at async Server.acceptConnAndIterateHttpRequests (https://deno.land/std@0.50.0/http/server.ts:221:14)
at async MuxAsyncIterator.callIteratorNext (https://deno.land/std@0.50.0/async/mux_async_iterator.ts:28:29)

We need a way to iterate that allows errors to be caught when iterating on HTTP server.