@“Peter_Viscarola_(OSR)” said:
That appears to be the case, yes.
I’m working feverishly to pull-together a post on the state of cross signing for down-level OS support (such as Win 7) to follow up what I wrote back in October.
Of course this doesn’t help you on Win 10.
Stay tuned,
Peter
Hi Peter
I came upon this thread, and it got me really confused, so i contacted Entrust, and it seems like this in fact is not True, and Entrust just like other CAs will not be able to give code signing EV certificates that can be used to cross sign drivers until 2025, and no matter what it seems like everyone will have to go through Microsoft Hardware Dev center to get their drivers signed, but please correct me if I’m wrong. This is the answer that i got :
“”“”"
I believe this all started with this post from Microsoft, https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates. This post calls out a cross-certificate to root Entrust.net Certification Authority (2048) which expires 15 April 2021. The issuing CA was L1D, which stopped issuing certificates at the end of 2016 due to SHA-1 issues. Those certificates did have a kernel-mode EKU. All of those certificates have expired, so kernel-mode code signing has already stopped.
Since mid-2015 all SHA-2 code signing certificates are issued from our OVCS or EVCS issuing CAs. These issuing CAs are subordinate to Our G2 CA cert. G2 was also cross-certified by Microsoft. If a customer wants to have kernel-mode code signing, then the code must be signed by both Microsoft and the customer using an EV Code Signing certificate, see https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#f-windows-10-kernel-mode-code-signing-kmcs-requirements. More details are found here, https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/.
All of this is not new, but I assume that Microsoft put out the notice to kill the old kernel-mode code signing. This did not impact Entrust, since we had already stopped issuing the certificates and they should have been expired at the notice time.
Note, we only started issuing EV Code Signing certificates in 2015 to allow our customers to submit code to Microsoft for kernel-mode signing.
“”“”"
So it seems like all EV certificates that CAs issue will only be useful for submitting drivers in Microsoft Hardware dev center, and nothing more ( in terms of kernel driver loading), but if anyone knows anything else, please let me know.
@john_smith1978 said:
I believe this all started with this post from Microsoft…
Lots of interesting information there, and appreciate it being shared. At least to my reading, Entrust’s info there ultimately leaves the main question unanswered, though. Since our “big confusion” was not regarding the “Entrust.net Certification Authority (2048)” cross-certificate and the Entrust certificates it applied to.
The response confirms all Entrust SHA-256 code signing certificates after 2015 are issued from CAs subordinate to the G2 CA. And we know the G2 CA does have a Microsoft cross-certificate that doesn’t expire until 2025, which this response from Entrust also acknowledges “G2 was also cross-certified by Microsoft”.
Which continues to beg the question: If I have an extended-validation SHA-2 code signing certificate issued by Entrust in 2016 or later, does this work today with the Microsoft cross-certificate for Entrust G2? Which in turn would imply that it would continue to work beyond 2021?
It seems like after the “G2 was also cross-certified by Microsoft” statement, the Entrust response switched to “the Microsoft party line” in which Dev Center is the only answer; without addressing the fact that G2 still has a valid cross-certificate.
Maybe someone else reads that differently, as you also apparently did. Is there anything except Entrust’s statement of “If a customer wants to have kernel-mode code signing, then the code must be signed by both Microsoft and the customer…” that led to your conclusion of “all EV certificates that CAs issue will only be useful for submitting drivers in Microsoft Hardware dev center”?
Because that’s what seems to be currently missing from my reading of it. The “why” this would be true.
edit: Removed reference to organization-validation certificate, since Entrust.com confirms those do not support kernel-mode code signing.
@Alan_Adams said:
@john_smith1978 said:
I believe this all started with this post from Microsoft…
Lots of interesting information there, and appreciate it being shared. At least to my reading, Entrust’s info there ultimately leaves the main question unanswered, though. Since our “big confusion” was not regarding the “Entrust.net Certification Authority (2048)” cross-certificate and the Entrust certificates it applied to.
The response confirms all Entrust SHA-256 code signing certificates after 2015 are issued from CAs subordinate to the G2 CA. And we know the G2 CA does have a Microsoft cross-certificate that doesn’t expire until 2025, which this response from Entrust also acknowledges “G2 was also cross-certified by Microsoft”.
Which continues to beg the question: If I have an extended-validation SHA-2 code signing certificate issued by Entrust in 2016 or later, does this work today with the Microsoft cross-certificate for Entrust G2? Which in turn would imply that it would continue to work beyond 2021?
It seems like after the “G2 was also cross-certified by Microsoft” statement, the Entrust response switched to “the Microsoft party line” in which Dev Center is the only answer; without addressing the fact that G2 still has a valid cross-certificate.
Maybe someone else reads that differently, as you also apparently did. Is there anything except Entrust’s statement of “If a customer wants to have kernel-mode code signing, then the code must be signed by both Microsoft and the customer…” that led to your conclusion of “all EV certificates that CAs issue will only be useful for submitting drivers in Microsoft Hardware dev center”?
Because that’s what seems to be currently missing from my reading of it. The “why” this would be true.
edit: Removed reference to organization-validation certificate, since Entrust.com confirms those do not support kernel-mode code signing.
Hi Alan,
Yeah their answer confused me as well and i am still not really sure if i got my answer or not. although they did emphasize that we have to go through Microsoft hardware lab to sign drivers from now on, so again, very confusing.
I suggest other people start contacting them as well, maybe if enough people started to ask them questions they clarify things ones and for all…
Technically, I see only three possibilities:
- It will work for cross signing until ~2025
- It will not load, and Entrust is actually aware that MS might
intentionally break that functionality via a Windows Update or
something
- The cross cert is NOT used for EV SHA2 certificates, in which case,
yeah, cross signing might work, but will be useless (Windows 10
requires cross signing via SHA2 EV certs than chain to the issuer’s
SHA2 EV root)
Since the cross-certificates have to be issued by Microsoft, I’m confused as to how these long term cross-certs came to be.
(Windows 10 requires cross signing via SHA EV2 certs than chain to the issuer’s SHA2 EV root)
We know that’s not true, right? EV vs non-EV is irrelevant to the cross-signing mechanism. EV is only a requirement for creating a Hardware Dashboard account.
You cannot cross sign a driver with an OV certificate and have it load on
Win10.
At least it never worked for me, unless the driver was signed before ~June
2015.
@Dejan_Maksimovic said:
You cannot cross sign a driver with an OV certificate and have it load on Win10.
At least it never worked for me, unless the driver was signed before ~June 2015.
Same with EV. They have no difference in this respect.
OK… I’ve moved my post to a new thread so it’ll be more visible to those who haven’t been following this topic:
New thread here.
Peter
@john_smith1978
Since mid-2015 all SHA-2 code signing certificates are issued from our OVCS or EVCS issuing CAs. These issuing CAs are subordinate to Our G2 CA cert. G2 was also cross-certified by Microsoft…
If “subordinary to” technically means “chain-up to” (which would be reasonable) then such a cert **should **be usable with the G2 cross-cert to cross-sign drivers, and let them load on down-level versions of Windows. The only catch is if MSFT decides to revoke the root cert to which the cross-cert chains up. That doesn’t seem realistic, though. Everything that chains-up to that cert would be invalidated.
I wish Entrust would make it easier to buy a Code Signing Cert from them… OV would be sufficient for this purpose.
I hope somebody gets one of these, cross-signed, and posts the cert chain so we’ll all know for sure.
Peter
@“Peter_Viscarola_(OSR)” said:
I wish Entrust would make it easier to buy a Code Signing Cert from them… OV would be sufficient for this purpose.
I hope somebody gets one of these, cross-signed, and posts the cert chain so we’ll all know for sure.
We are working on getting the Entrust EV. It will take a while, but as soon as I lay my hands on it, I’m going to check the chain (unless someone else manages to get it sooner).
@CaptainFlint
Thanks, Captain. We’ll be grateful for whatever info you can provide.
Peter
@CaptainFlint said:
@“Peter_Viscarola_(OSR)” said:
I wish Entrust would make it easier to buy a Code Signing Cert from them… OV would be sufficient for this purpose.
I hope somebody gets one of these, cross-signed, and posts the cert chain so we’ll all know for sure.
We are working on getting the Entrust EV. It will take a while, but as soon as I lay my hands on it, I’m going to check the chain (unless someone else manages to get it sooner).
Hi Flint,
Any update on that Entrust cert? did you get it? If so, can you please post the cert chain for us, so we can see if it in fact chains up to G2 CA?
You did see that MSFT said they would revoke the cert for anyone who used it after 1 July 2020 for cross-signing drivers for down level OS versions, right?
Not sayin’ this makes your question invalid… just wanted to be sure you saw MSFT’s most recent position on this.
Peter
@henrik_meida said:
Any update on that Entrust cert? did you get it? If so, can you please post the cert chain for us, so we can see if it in fact chains up to G2 CA?
Unfortunately we met with some difficulties during the company verification stage, which have never occurred before. My colleagues are still fighting it… 
@“Peter_Viscarola_(OSR)” said:
You did see that MSFT said they would revoke the cert for anyone who used it after 1 July 2020 for cross-signing drivers for down level OS versions, right?
Not sayin’ this makes your question invalid… just wanted to be sure you saw MSFT’s most recent position on this.
Peter
Yes i saw that, but we might have a shot at asking Microsoft for permission of cross signing with that cert only for supporting older operating systems like 7, i know its unlikely for them to accept but worth the shot. and we would obviously tell them why we can’t pass the WHQL test for some of our drivers.
@CaptainFlint said:
@henrik_meida said:
Any update on that Entrust cert? did you get it? If so, can you please post the cert chain for us, so we can see if it in fact chains up to G2 CA?
Unfortunately we met with some difficulties during the company verification stage, which have never occurred before. My colleagues are still fighting it…
Would you mind telling us what exactly they did for verification? and what were these difficulties? I thought the EV verification process is pretty straight forward?!
@henrik_meida said:
Would you mind telling us what exactly they did for verification? and what were these difficulties? I thought the EV verification process is pretty straight forward?!
I’m not sure how much I’m allowed to disclose, it may be considered sensitive information. But basically, it now requires some third-party independent sources to confirm the information we provide. And some of the required data were not available via any of the sources, which the verification service considered trusted. So we are arranging legal confirmations that would satisfy Entrust, but it takes time.
@CaptainFlint said:
@henrik_meida said:
Would you mind telling us what exactly they did for verification? and what were these difficulties? I thought the EV verification process is pretty straight forward?!
I’m not sure how much I’m allowed to disclose, it may be considered sensitive information. But basically, it now requires some third-party independent sources to confirm the information we provide. And some of the required data were not available via any of the sources, which the verification service considered trusted. So we are arranging legal confirmations that would satisfy Entrust, but it takes time.
So I’m assuming you didn’t have a DUNS number, correct? because based on what i heard, having one will conclude the verification process.
We are in the process of getting one, and after that we’ll try Entrust. But please do update us when you finally got your certificate.
@henrik_meida said:
So I’m assuming you didn’t have a DUNS number, correct? because based on what i heard, having one will conclude the verification process.
No, it’s not the DUNS that caused problems. As I said, we have already been buying EV certificates before, and never had any issues.
But please do update us when you finally got your certificate.
I certainly will. 
we might have a shot at asking Microsoft for permission of cross signing with that cert only for supporting older operating systems like 7
You might note that this is precisely the circumstance for which they are threatening to revoke your cert. not any other situation. I’ve personally advocated, asked, pleased, and explained. And the last reply I got was “see this new section of this document”… which was the threat to revoke the cert.
They’re not going to help us. Period. Full stop.
Peter