SEP debugger - continued issues with 'Self signed certificate' error #2320
Comments
|
@heymchri Here are the things you can try:
|
|
The most likely cause is that the host file debug_service.crt and the client file %HOSTNAME%_debug_service.crt do not match. |
|
@mkwan01 I can no longer seem to reproduce this, so I will close this issue. Maybe something in VS Code for i changed since I had this issue at 2.13.5 but I'm now at 2.13.6. Anyways, thanks for the pointers and I'll open a new issue if I run into this again in the future. |
|
@mkwan01 I'm reopening this issue - after installing a cert signed by an external CA, when trying to set a SEP, I get this error: Testing the debug SSL connection shows: I did a diff to compare my local crt file vs. the one on the IBM i - they are identical. .log file shows: |
|
@heymchri We want to know whether this issue is specific to CA signed certificates. As the first step, can you verify whether the debug connection is OK if you use the Code for IBM i generated certificate? The Code for IBM i generated certificate is a self-signed certificate without a CA. Your new certificate seems to be a chained certificate that contains two intermediate CAs and one root CA. |
|
If the issue is specific to CA signed certificates, please open the local debug_service.crt file in an editor and report how many certificates are contained in the .crt file. If the .crt file contains multiple blocks of "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" clauses, then it contains multiple certificates. I would guess the .crt file only contains one certificate in your case. |
|
@mkwan01 I can't make sense of what's going on - I've been debugging all last week with internal certs (just regular batch debugging - no SEP). This morning I reconnect to the system, try to debug, and I get the dreaded 'Self Signed Certificate' error again. I try a bunch of scenarios, regenerating internal cert, quitting/restarting VS Code, installing CA cert, etc. but no matter what I do, I keep getting the 'Self Signed Certificate' error, on both partitions I'm testing with. I then must have done something different as suddenly the issue goes away and I can debug as batch with the internal cert on one of the partitions, and when I then go back to the other partitions, it magically works there as well now (although I didn't make any changes to that partition). So it almost seems like some kind of caching issue? I then try to install the CA signed cert on that second partition, and lo and behold, I now get the 'self signed certificate in certificate chain' error. Output of the 'openssl s_client -host usalid06.infor.com -port 8005' command: |
|
@heymchri Does the second partition have a different host name or IP address? The generated certificate could be signed with the hostname or IP. If the hostname or IP is different, then we need to regenerate the certificate. As you have a chained certificate, one other option you can try is to generate a .pem file instead of the .crt file and make sure that the .pem file includes all certificates in the chain. You can then rename the .pem to a .crt on the client machine and see whether the new .pem that includes all certificates would work. |
|
@heymchri One other thing you can try is to insert the following launch configuration into the VS Code launch.json file in the problem partition and use this launch config to start a debug session: { The only difference between this and the integrated launch is the "ignoreCertificateErrors" attribute. It is set to false in the integrated launch. You can report back whether this solution works for you. |
|
Hi @mkwan01 next time I run into a 'Self Signed Certificate' error, I'll try your launch configuration suggestion. |
|
@mkwan01 just ran into the 'Self Signed Certificate' error again. Was working OK yesterday. Seems to happen whenever I switch between partitions. In any case, I tried the launch configuration and that worked - debug editor came up without error messages. |
|
@mkwan01 Also of note: I disconnected from the system, quit VS Code, restarted it, reconnected to the system, and the regular Debug as Batch function (i.e., not using the launch config) worked just fine - no cert errors. Didn't make any config changes at all in between. So at almost seems something is being cached that shouldn't, and it gets reset when exiting/restarting VS Code? |
|
@mkwan01 I ran into the 'self signed certificate' error again this morning - not only for SEP debugging for also for regular batch debugging. The error message showed up for all systems I tested (4 partitions). Disconnecting/reconnecting, stopping/restarting the debug service job, exiting/restarting VS Code didn't help. I then regenerated the cert for one of the partitions, and that fixed the issue not only for that partition, but also for the other 3 partitions. |
When trying to set an Service Entry Point, I frequently get an error message:
"EQAVS1007E xxxxxxx.yyyyy.COM on port 8005 could not be connected.
Message received: self signed certificate"
Why is this happening? This is the cert that gets generated by the Debug Service. Is there a setting somewhere that causes self signed certificates to be disallowed? We use other self signed certs on this same partition without issues.
Also, when trying to use an external CA signed cert (Sectigo), I get the issue described in #2309.
Active extensions
Remote system
Enabled features
Shell env
Variants
{ "american": "#@$", "local": "#@$" }Errors
[ { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPF4102: File EVFEVENT in library QGPL with member EDNRPGLE not found.\nCPF2803: To-file EVFEVENT in QGPL not allowed.\nCPF2817: Copy command ended because of error.", "cwd": "/home/HEYMCHR" }, { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPD0048: List of values not valid for parameter FILE.\nCPF0001: Error found on DSPFFD command.", "cwd": "/home/HEYMCHR" }, { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPF3012: File OBJFPCLA in library *LIBL not found.", "cwd": "/home/HEYMCHR" } ]The text was updated successfully, but these errors were encountered: