Debug server certificate generation "invents" server domain name

[zkarj735]

I'm trying to get debugging working and have hit this issue when trying to create the server certificate.

My connection was originally called just "ia117" and used a connection address of the same. I also tried setting one or both to the a fully qualified name (not the one shown in the error) but I continue to get the same error. I don't know where it is coming up with this domain from, but it won't work.

My company changed its name some years back so we still have a mix internally. I need to be explicit with the domain this is using. How can I do that?

---

Context	Version
Code for IBM i version	2.12.1
Visual Studio Code version	1.89.1
Operating System	win32_x64

Active extensions

``` CL (vscode-clle): 1.1.7 COBOL (cobol): 10.6.15 Code for IBM i Walkthroughs (vscode-ibmi-walkthroughs): 0.5.0 Db2 for IBM i (vscode-db2i): 1.1.1 Emmet (emmet): 1.0.0 Error Lens (errorlens): 3.20.0 Extension Authoring (extension-editing): 1.0.0 Git (git): 1.0.0 Git Base (git-base): 1.0.0 Git Branch Warnings (branch-warnings): 1.0.10 Git Graph (git-graph): 1.30.0 GitHub (github): 0.0.1 GitLens — Git supercharged (gitlens): 15.2.3 IBM i Debug (ibmidebug): 2.0.1 IBM i Notebooks (vscode-ibmi-notebooks): 0.0.6 JSON Language Features (json-language-features): 1.0.0 Merge Conflict (merge-conflict): 1.0.0 Microsoft Account (microsoft-authentication): 0.0.1 NPM support for VS Code (npm): 1.0.1 Node Debug Auto-attach (debug-auto-launch): 1.0.0 Server Ready Action (debug-server-ready): 1.0.0 TODO Highlight (vscode-todo-highlight): 1.0.5 Todo Tree (todo-tree): 0.0.226 TypeScript and JavaScript Language Features (typescript-language-features): 1.0.0 ```

---

Remote system

|Setting|Value| |-|-| |IBM i OS|V7R4M0| |Tech Refresh|10| |CCSID Origin|65535| |Runtime CCSID|65535| |Default CCSID|37| |SQL|Enabled |Source dates|Disabled ### Enabled features |/QOpenSys/pkgs/bin|/usr/bin|/QSYS.lib/ILEDITOR.lib|/QSYS.LIB|/QIBM/ProdData/IBMiDebugService/bin| |-|-|-|-|-| |bash|attr|GETNEWLIBL.PGM|QZDFMDB2.PGM|startDebugService.sh| |chsh|iconv|||| |find|setccsid|||| |git||||| |grep||||| |ls||||| |md5sum||||| |sort||||| |stat||||| |tar||||| |tn5250|||||

Shell env

```bash BUILDLIB=QGPL CURLIB=QGPL HOME=/home/T816416 HOST=ia117 HTTPS_PROXY=xxxxx.xxxxx.xxxxx:80 HTTP_PROXY=xxxxx.xxxxx.xxxxx:80 LIBLS=PCSDTATCNZ PCSSWTCNZ PCCDTA IOMSDTA IOMSSW QGPL PCCMISC PCCSW TAATOOL DAGDTA DAGSW QTEMP LOGIN=t816416 LOGNAME=t816416 MAIL=/var/spool/mail/t816416 OLDPWD=/home/T816416 PATH=/QOpenSys/pkgs/bin:/QIBM/ProdData/mqm/bin:/fmlcl/scripts:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin PWD=/home/T816416 SHELL=/QOpenSys/pkgs/bin/bash SHLVL=1 SSH_CLIENT=10.116.29.132 55191 22 SSH_CONNECTION=10.116.29.132 55191 146.171.64.117 22 TZ=-12,M9.5.0,M4.1.0/03:00:00 USER=t816416 USERNAME=t816416 WORKDIR=/home/T816416 _=/QOpenSys/pkgs/bin/env no_proxy=.xxxxx.xxxxx.xxxxx,.yyyyy.yyyyy.yyyyy,.zzzzz.zzzzz.zzzzz ```

Variants

```json { "american": "#@$", "local": "#@$" } ```

Errors

```json [ { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPF2111: Library ILEDITOR already exists.\nCPC2206: Ownership of object QZSHSYSTEM in QTEMP type *USRSPC changed.", "cwd": "/home/T816416" }, { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPF9801: Object QCPTOIMPF in library QSYS not found.\nCPC2206: Ownership of object QZSHSYSTEM in QTEMP type *USRSPC changed.", "cwd": "/home/T816416" }, { "command": "/QOpenSys/usr/bin/qsh", "code": 1, "stderr": "CPF9801: Object QCPFRMIMPF in library QSYS not found.\nCPC2206: Ownership of object QZSHSYSTEM in QTEMP type *USRSPC changed.", "cwd": "/home/T816416" } ] ```

[worksofliam]

@zkarj735 At what point are you getting this error? You're saying you can't get debug started, but that error looks like a connection error. Thanks!

[zkarj735]

It's definitely a connection error because it's choosing to use a domain name which will not resolve.

The actions I am taking are:

1. Hover over the connection name and click the "Debugger 1.0.0 (off)" entry in the menu that pops up.

2. Click the icon at the right of the "Remote certificate not found..." error.

This gives rise to the error I showed above.

The problem is Code for i (or something it uses) is deciding to qualify the server name with "newname.com" which will not resolve. It has to be either unqualified or use "oldname.com".

As can be seen from the pings below the first two work and the last doesn't. It's this one that is being used, seemingly beyond my control, when attempting to connect to establish the certificate.

So the questions are where does it get newname.com from and why, and can I override it somehow?

[chrjorgensen]

@zkarj735 The debug SERVICE certificate is generated on the server by using the hostname and domain found in the TCP/IP settings on the server (CFGTCP option 12). Seems like this information is not correct or does not have been changed when your company changed its name (and network domain).

I see a few possible solutions:

1. Add the generated name ia117.newname.com to the HOSTS file on your workstation (to make it work for you only).
2. Add the generated name ia117.newname.com to the DNS server (to make it work for all users on the network).
3. Change the hostname and/or domain on the server (CFGTCP option 12) to the correct, current domain.

It's important to keep the network information current on the server - said the IBM i system admin! :laughing:

[sebjulliand]

I'll second @chrjorgensen on this. The LPAR network configuration seems to be wrong here and wasn't updated after the domain name was changed. Better check the host tables on this IBM i too!

Besides, overriding the hostnames used to generate the certificate may not even help since it plausible the debug service will try to match the certificate hostnames with the LPAR's (not sure about this though, the debug extension and debug service are closed source projects solely owned by IBM).

[zkarj735]

Thanks, I had assumed it was obtaining the name from my PC, but now I know it's the server, it makes some sense.

We don't have administrator access to our PCs, so the easy option of editing HOSTS is not available. However, I am now wondering why our TCP/IP Domain on the server is set to newname.com yet these are not present in the DNS. That seems like the proper correction to be made.