rvk

What color banner does it show then if you start up those programs? I'm sure it's not this (below) blue banner because there is no verified producer name. So it will still show you the other yellow banner. It won't prompt smartscreen because that's something different. But it will probably you that install screen with yellow banner and no certificate warning. But yes, you need to adjust your workflow now to incorporate the new certificate

Maybe that's true for the full blue screen (where you need to tap more info). I don't think it's true for the install screens you showed in that article (blue banner for valid and yellow for invalid or not present). At least it shouldn't because that screen shouldn't get the info from smartscreen but directly from the certificate in the executable.

Not if used on a new computer. I don't know what happens on existing computers. But it's never wise to not sign with a timeserver. And maybe it passes smartscreen during download but it will not give you the blue screen when installing but a yellow screen promoting the expired certificate.

Yep. Then you can take that article down because it's based on old information. You can't do it like that anymore with new issued certificates. And you signed with the old certificate in that article. Also... all you previously signed exes will complain after that date. That's why you need to sign with a timeserver so those exes will keep working, even after the date of expiration of the certificate with which you signed.

O wow, then you didn't even signed with a timeserver with timestamp (which means the signed exe will complain when the certificate expires). Normally you sign with the timeserver so the exe will be usable also after your certificate expires. You just can't sign new exe anymore with an expired certificate. Because you didn't, and don't seem to be able to go to the real certificate, it leads me te believe you didn't even check things. Now do the same as before (right click exe, properties, certificate tab) but now click a SHA256 and click Details. Then click View certificate. There you have "Issued to", "Issued by" but also "Valid from/to". What are the dates there?

No, you need to right click the file and go to properties. Choose the certificate tab and see if it had the new certificate. That command just shows you still have a valid verificatie but that could still be the certificate which you can't use anymore after the spring to sign new files after that.

Can you check the actually signed exe file? Did it really contain the new certificate. I still have a feeling you are working with old files because the new method shouldn't allow token-less certificates anymore. So the old pfx isn't allowed anymore after it expires. https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022 That mail is from the old way of doing things before 2023. So if you used the pfx from there... Then that's not going to work anymore after the certification expires in a few months.

Luckily I should get a usb stick when my 3 years run out (including a certificate for another year) as part of the promo when they switched to the new form. But you said you have a pfx without a usb stick and don't need a password. How does that work? How did you get that from sectigo? If you only have a pfx this is portable to another computer/developer without the usb stick present. That shouldn't be possible anymore. How did you get the pfx? Mail of usb stick? And if you did get the usb key how did you extract the pfx from that? Edit: I wonder if you are not just signing with an old certificate

So Sectigo is still selling certificates which can be used as .pfx directly with signtool.exe without providing a prompt ? So why are they providing a USB stick then? This could just be done electronically via mail.

I've just tested with a server which can't do HTTP/2 (but only does HTTP 1.1) and it always returns OK inside the service. So I think the problem is that, when running as local system account. the HTTP/2 is requested. If it's not available, you'll get the OK. If HTTP/2 is available, there is no OK. Maybe you can test it with a server where you always get a HTTP1.1 result (and never a HTTP/2 result). You can also test this yourself by logging res.Version. I didn't test it but I'll bet you'll get version 2 back for no OK, and 1.1 for OK. THTTPProtocolVersion = (UNKNOWN_HTTP, HTTP_1_0, HTTP_1_1, HTTP_2_0); Grrr. Nope. Also not it: I give up 🙂

Your welcome. BTW. I just tested curl on a Linux machine (just for fun): Notice the absence of OK on the HTTPS result. HTTP did give OK 😉 HTTPS is HTTP/2 (not 1.1) so maybe we are getting HTTP/2 back. Forcing curl to do http 1.1 will give OK. sudo curl --http1.1 -I https://www.google.com But yes... you don't need to worry about the reason-phrase. It should be ignored anyway.

Only start the timer during the start service sequence. But that's besides the point for this problem. BTW. The reason-phrase is optional in the http-protocol. See https://datatracker.ietf.org/doc/html/rfc9112#name-status-line Also it says that you should ignore it.

Fun part is that if you do "project /install" (from an admin console) it momentarily runs as administrator. It then also runs the TTimer function and does give the OK correctly. (running in a user console also gives OK but then the service doesn't get installed obviously) You didn't put the TTimer.Enabled only for running the service but for every run, so also for the /install and /uninstall runs. After actually starting the service, it'll run as limited local system account, the TTimer function runs again but now the OK is not shown 😉 So I can confirm this on Windows 10, Delphi 10.2 (object pascal). So it's really the local system account in a service that's the problem here. Might limit the search.

Oops. Hadn't noticed this was C++. Because this was posted in "RTL and Delphi Object Pascal" But I'm sure someone can test and confirm this. But am I understanding it correctly that it now always runs correctly as App and only fails as Service? Does the service run as user or admin? Did you test it the other way around?

Could be that it's only a problem in service. Try to create a simple test project. If you can consistently let it fail, we can test it too. And if it's only in service that's also an indicator for which you can search.