@servicedesk-pianezza Confirmed, and your fix is the right one. Thanks for the clear report.
The check was using the 24-character Base24 alphabet. That set is what you use to decode an older key into its binary form, and N is not one of its digits. It is not the set of characters a key is printed with. Windows 8 and later put N in the key itself, so any key carrying one was refused at entry.
There was a second half of the same bug. The browser keeps its own copy of that character list, for the masked display of a saved key. So even where a key with an N got stored, the page showed it as five groups of dots instead of keeping the first and last group. Both copies now say the same thing, and a test compares them character for character so they cannot drift apart again.
The test also runs Microsoft’s published KMS client keys through the validator, and checks that the characters Windows leaves out (A E I O U L S Z 0 1) are still rejected and the length is still exactly 25.
It is in PR #1773 against working-1.6: https://github.com/FOGProject/fogproject/pull/1773
It will be in the next beta build. If you would rather not wait, the one-character edit you already made is exactly what landed.