[SOLVED] SubjectAltNameWarning

[lowix]

- Installed WAPT version: 1.7.4
- Server OS: Linux
- Operating system of the administration/package creation machine: Windows 10

Good morning,
Since I applied the 1.7.4 update, I get this warning message when a package is installed:

Code: Select all

C:\Program Files (x86)\wapt\lib\site-packages\urllib3\connection.py:362: SubjectAltNameWarning: Certificate for srv-wapt15.iut-acy.local has no `subjectAltName`, falling back to check for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
  SubjectAltNameWarning

It's not a major issue, but I'd like to understand and resolve it…
Thank you for your answers

[sfonteneau]

Hello,

this is just a warning.

In older versions of WAPT, we generated a self-signed certificate during installation without the "subjectAltName" attribute.

And as the message indicates, based on RFC 2818, a certificate without "subjectAltName" is not supported by RFC 2818.

We need to post a procedure to renew and regenerate this certificate without any side effects.

If your WAPT agent is configured not to verify the HTTPS certificate, then it will be simple; otherwise, we need to create a procedure.

Simon

[crismatinfo]

Hello,
I just joined the forum following the JRES Marseille conference.
I'm having the problem of the message "SubjectAltNameWarning: Certificate for 'my server' has no `subjectAltName`" because I had version 1.7 which I upgraded to 2.2. Before buying my 200 licenses, I'd like to resolve this small issue.

sfonteneau, you said, "We should post a procedure to renew and regenerate this certificate without any side effects.
"
Q: Does such a procedure exist?

Thank you for your help,
Eric

[sfonteneau]

Hello,

I wrote a procedure here that still works:
https://lists.wapt.fr/pipermail/wapt/20 ... 03795.html

Are you correctly verifying your HTTPS certificate?

Simon Fonteneau

[olaplanche]

Hello,

FYI, I am also in this situation.

[dcardon]

Did Simon's solution solve your problem?

Denis

[olaplanche]

Hello,

I just tested the procedure provided by Simon and something is puzzling me!

After restarting the post-configuration, the name of the .crt file generated in the /root/ folder doesn't match the server's FQDN.
The .crt file name is identical to the name of the .crt file located in my c:\private folder on my administration machine.
However, in the C:\Program Files (x86)\wapt\ssl\server\ folder, I do have a .crt file with the server's FQDN!
I still followed the procedure and deployed the new agent on a test machine. The problem is still not solved...

Any ideas?

Thanks

[sfonteneau]

Hi,

where are you in the process?

You mention /root, but the procedure specifies a new and old folder.
You also mention c:\private; be aware that this certificate has nothing to do with package creation, it's solely the HTTPS certificate.

[olaplanche]

My mistake, I think I misinterpreted the `cat` command due to my limited Linux knowledge (the presence of another `crt` file in the root directory misled me).

I just repeated the procedure, and if I understand correctly, the `cat` command creates a new `crt` file and doesn't modify an existing one.
Once the `srvwapt.mydomain.lan.crt` file is generated, I copy it to my administration machine in the folder `C:\Program Files (x86)\wapt\ssl\server\srvwapt.mydomain.lan.crt` and then generate a new client from the console. I deploy it to a test machine and I still get the `SubjectAltNameWarning` error when simply typing the command `wapt-get update`.

[sfonteneau]

If the old certificate on the server is in /opt/wapt/waptserver/ssl/, that's normal;

if the new one is in /opt/wapt/waptserver/ssl/, that's not normal

(remember to restart nginx).