Meta: I'm not convinced this is programming or development, but I need space and formatting. I agree to deleting this if the Q is voted closed.
... postman gives ... 10000416:SSL routines:OPENSSL_internal:SSLV3_ALERT_CERTIFICATE_UNKNOWN
Request is not hitting the endpoint. (I don't see any server level logs).
This is literally true, but the error IS from the server = your endpoint. The way HTTPS works is the client, here postman, connects to the server, here endpoint; the two systems then start an SSL/TLS session using a fairly complicated 'handshake' process; and finally the client sends the HTTP request to the server within the SSL/TLS session. This error is occurring before the handshake completes and thus before the request is sent, hence no logged request, but postman did connect to the server and send the certificate as part of the handshake, and the server rejected it.
The relevant question is why; alert 46 covers many possible cases. If the server has any other log(s) (like apache usually has separate access_log and error_log) check it/them. If not, looking very carefully at the certs you generated and understanding how they should work may help. There are two possibilities that spring out at me:
the webpage you followed is intended for creating a server cert, not a client cert. While the actual generating in openssl can be the same, the way you trust the result may be different, and in particular depends critically on what the server (endpoint) software is -- apache? nginx? haproxy? IIS? Tomcat/Wildfly? nodejs/express? etc? etc?
the statement in that webpage that the (subject) Distinguished Name for the server (or other end-entity such as your client) "don’t matter" is dangerously incomplete. It doesn't matter exactly what the DN is, but it does matter what it is NOT: it must NOT be identical to the DN of the CA cert, as the example given almost but not quite is (it differs only in the email address).
As an aside: unlike an SSL/TLS server cert, which absolutely does need the SubjectAltName (SAN) extension as stated there, an SSL/TLS client cert does not. However, having it unnecessarily present shouldn't be a problem.
If your problem isn't indicated by the server log(s) or one of those obvious ones, I would first try replacing the server with the test tool openssl s_server using this cert-and-key (and -www so that a requester like postman can get a valid response) and see if that works: if so, the problem must be your server (endpoint); if not, we know it's the cert(s) and need to look at it/them in detail.
Also I tried with curl ... Same error
curl: (58) schannel: Failed to import cert file ratha-testlocal.crt, last error is 0x80092002
That's not the same error at all. Many variants of curl, especially on Linux, use OpenSSL, and can use for --cert and --key the files created by OpenSSL -- though in that case you should use the entity cert and entity key, not the root key. However curl can use other protocol libraries, and your variant, apparently the one supplied by Microsoft for Windows 10 up, uses schannel instead of OpenSSL, so it cannot use these files for a client cert-and-key, instead it must use an entry in the Windows cert store, usually the 'MY' section (shown as 'Personal' in MMC/certmgr). See the man page . If you did put your cert-and-key in the cert store and reference it there, you should get a similar error from curl as from postman, but not quite the same, because schannel generally provides less detail about errors than OpenSSL does.
