I recently installed TeXLive 2016 on a partition where I run Windows 7 Ultimate SP1 OS (Italy-localized). I am experiencing some problems with the installation of the additional fonts. Following the instructions I found in many sites, I downloaded and also successfully ran the appropriate script install-getnonfreefonts. Then I tried to execute getnonfreefonts-sys -a to get and install all the fonts but I received an error message telling that the SSL certificate issued by tug.org is not valid. This error prevented wget.exe to run and do the right job. A Google search shows that some time in the past a specific question about this problem had been posted here but the related thread is currently unavailable because that question (together with all its answers) has been removed. As it stands, I cannot tell whether it is an OS issue (I did not find anything useful on the web) or there may be something wrong with TeXLive. I succeeded in catching an image from my Windows console I got by trying to obtain a list of additional fonts:

Error message

As it can be easily noticed, error message comes with the exact IP address (and port number) of tug.org.

  • Exactly which URL is it that it does not trust? Please always cite the explicit error messages. – daleif Nov 7 '16 at 11:49
  • Strange because Firefox does trust it. Might be an idea to take it to the texlive list (I'm not sure of the developer read TSE) – daleif Nov 7 '16 at 14:33
  • I just tried updating garamondx that used to fail with this problem; now it works. – egreg Mar 13 '17 at 20:57

One easy solution to that problem is to change the source code of the script. Just search for ~kotucha within the file (C:\texlive\2016\texmf-dist\scripts\getnonfreefonts\getnonfreefonts.pl, should yield 1 hit) and then change https to http.

Although that of course lessens the security on transport, it will at least get the script to proceed. And that is what was important to me (in March 2017, TL2016 on Windows). As @egreg pointed out for him it was not necessary, so probably it also depends on your computer.

| improve this answer | |
  • You should at least mention the security implications. Especially given that there is no reason to do this according to egreg's comment above. So you are recommending less security for no benefit. – cfr Mar 14 '17 at 0:57
  • @cfr For me there was a reason, because I did get the same error as the OP. That was the easiest fix I could find (given that I was not able to clearly identify the wget line to pass --no-check-certificate). – TeXnician Mar 14 '17 at 5:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.