Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Vista 64-bit code signing: "windows can't verify the publisher of this driver"

jpeskinjpeskin Member Posts: 4
This has come up before on NTDEV and other newsgroups, but the answers are
conflicting. I'm hoping for a more authoritative answer.
I have obtained an SPC from GlobalSign and am attempting to sign a KMDF
driver by following the MSFT "Kernel-Mode Code Signing Walkthrough", using
inf2cat and signtool exactly as specified in the example. All procedures
succeed, and I am able to "signtool verify" successfully.

Installation on the Target machine goes fine, but during installation there
is a popup dialog "Windows can't verify the publisher of this driver". And
looking at the Driver tab under Device Manager shows "Not digitally signed"
for the driver (as well as for each file under "Driver Details").
Curiously, even the WdfCoInstaller says it is Not Signed, although I would
have expected MSFT to sign the binary itself.

Some prior posts on NTDEV suggest that unless you go through Winqual and get
a signature from MSFT, then these messages will always popup. However,
other posts suggest that some people have managed to not get this particular
popup after signing drivers (or some claim a popup at least shows the
correct Publisher name, which I have not seen with my signed drivers)

So is there mistake in my signing process? Or is it always normal for Vista
64 to raise this dialog on even signed drivers, if they do not have a
Winqual signature?

Thanks,
Jonah

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Lert me ask a few questions. Are you signing the .sys binary or the .cat
    fle? Or both? They are totally different signatures.

    During driver installation, you need the .cat signed. On Vista/W2K8 x64, you
    also need the binary signed.

    On Vista x64 the expected behaivor would be: the first time you install a
    driver with your Authenticode signature a dialog will come up, and it will
    have an option to "always trust drivers from xxx". To prevent this, you need
    either a) a WHQL signature, b) the the Authenticode cerificate already
    installed as I believe a trusted publisher. I belive you can get option B to
    happen via a network doman group policy, so all machines that are domain
    members will trust drivers from that company.You also can add the publisher
    certificate on first install, and then laters installs of that device should
    be silent.

    I'd have to verify if GlobalSign is a valid Authenticode certificate
    provider, with installed roots.

    On W2K3, there is no way to make an Authenticode signature work like a WHQL
    signature, although maybe on devices in a custom device class you can.

    Jan



    _____

    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of Jonah Peskin
    Sent: Monday, March 16, 2009 9:47 PM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] Vista 64-bit code signing: "windows can't verify the
    publisher of this driver"


    This has come up before on NTDEV and other newsgroups, but the answers are
    conflicting. I'm hoping for a more authoritative answer.

    I have obtained an SPC from GlobalSign and am attempting to sign a KMDF
    driver by following the MSFT "Kernel-Mode Code Signing Walkthrough", using
    inf2cat and signtool exactly as specified in the example. All procedures
    succeed, and I am able to "signtool verify" successfully.

    Installation on the Target machine goes fine, but during installation there
    is a popup dialog "Windows can't verify the publisher of this driver". And
    looking at the Driver tab under Device Manager shows "Not digitally signed"
    for the driver (as well as for each file under "Driver Details").
    Curiously, even the WdfCoInstaller says it is Not Signed, although I would
    have expected MSFT to sign the binary itself.

    Some prior posts on NTDEV suggest that unless you go through Winqual and get
    a signature from MSFT, then these messages will always popup. However,
    other posts suggest that some people have managed to not get this particular
    popup after signing drivers (or some claim a popup at least shows the
    correct Publisher name, which I have not seen with my signed drivers)

    So is there mistake in my signing process? Or is it always normal for Vista
    64 to raise this dialog on even signed drivers, if they do not have a
    Winqual signature?

    Thanks,
    Jonah
    --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
    other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
    List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,002
    Jan Bottorff wrote:
    > Lert me ask a few questions. Are you signing the .sys binary or the
    > .cat fle? Or both? They are totally different signatures.
    >
    > During driver installation, you need the .cat signed. On Vista/W2K8
    > x64, you also need the binary signed.

    This is not quite correct. The .cat signature is all you need in every
    case except one: an x64 driver that is used by the boot loader must have
    the signature embedded in the driver binary. That's the only
    exception. For all other drivers, the .cat signature is sufficient.


    > On Vista x64 the expected behaivor would be: the first time you
    > install a driver with your Authenticode signature a dialog will come
    > up, and it will have an option to "always trust drivers from xxx". To
    > prevent this, you need either a) a WHQL signature, b) the the
    > Authenticode cerificate already installed as I believe a trusted
    > publisher. I belive you can get option B to happen via a network doman
    > group policy, so all machines that are domain members will trust
    > drivers from that company.You also can add the publisher certificate
    > on first install, and then laters installs of that device should be
    > silent.

    You're talking about the "install time" behavior on all systems, not the
    x64 KMCS behavior. The x64 KMCS signature check happens every single
    time the driver is loaded. There are no easy policies to override
    that. You can either (1) attach a kernel debugger, (2) press F8 at boot
    time to turn it off, or (3) enable /testsign and install your
    certificate as a trusted root.


    > I'd have to verify if GlobalSign is a valid Authenticode certificate
    > provider, with installed roots.

    For KMCS, it doesn't matter. There is only one valid root provider
    (Microsoft), and you must embed a cross-certificate that chains from
    your provider to Microsoft.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Tim,

    It seems like you're both agreeing and disagreeing with what I said in two
    different paragraphs.

    Your reply said "an x64 driver that is used by the boot loader must have the
    signature embedded in the driver binary" and then your reply also said "The
    x64 KMCS signature check happens every single time the driver is loaded".

    My understanding is (unless you are in a special debugging/test mode) that
    EVERY x64 driver on Vista/W2K8 will need an embedded signature, no matter
    when it starts. Are you saying your believe a non-boot start x64 driver on
    Vista/W2K8 does not need an embedded signature, or am misinterpreting what
    your saying?

    Yes, I was not totally clear about the validity of a GlobalSign certificate,
    and yes there would need to be a valid certificate chain to a valid root,
    and that requires adding the correct cross-certificate. I always have used
    VeriSign certificates, so don't have any personal knowledge about using
    GlobalSign certificates.

    My overall point was that "signed driver" has multiple meanings, and the
    correct kind of signature is required for a desired purpose. Putting a KMCS
    signature on a driver will not make it show up as "signed" in device
    manager, or make it install silently. As I remember, a correctly signed
    .cat, and unsigned binary (on x64 Vista/W2K8) will show up as signed in
    device manager, but when the OS tries to start the driver, it fails with an
    error that says the binary is not signed.

    Jan


    > -----Original Message-----
    > From: xxxxx@lists.osr.com
    > [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
    > Sent: Tuesday, March 17, 2009 9:49 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re: [ntdev] Vista 64-bit code signing: "windows
    > can't verify the publisher of this driver"
    >
    > Jan Bottorff wrote:
    > > Lert me ask a few questions. Are you signing the .sys binary or the
    > > .cat fle? Or both? They are totally different signatures.
    > >
    > > During driver installation, you need the .cat signed. On Vista/W2K8
    > > x64, you also need the binary signed.
    >
    > This is not quite correct. The .cat signature is all you
    > need in every case except one: an x64 driver that is used by
    > the boot loader must have the signature embedded in the
    > driver binary. That's the only exception. For all other
    > drivers, the .cat signature is sufficient.
    >
    >
    > > On Vista x64 the expected behaivor would be: the first time you
    > > install a driver with your Authenticode signature a dialog
    > will come
    > > up, and it will have an option to "always trust drivers
    > from xxx". To
    > > prevent this, you need either a) a WHQL signature, b) the the
    > > Authenticode cerificate already installed as I believe a trusted
    > > publisher. I belive you can get option B to happen via a
    > network doman
    > > group policy, so all machines that are domain members will trust
    > > drivers from that company.You also can add the publisher
    > certificate
    > > on first install, and then laters installs of that device should be
    > > silent.
    >
    > You're talking about the "install time" behavior on all
    > systems, not the
    > x64 KMCS behavior. The x64 KMCS signature check happens
    > every single time the driver is loaded. There are no easy
    > policies to override that. You can either (1) attach a
    > kernel debugger, (2) press F8 at boot time to turn it off, or
    > (3) enable /testsign and install your certificate as a trusted root.
    >
    >
    > > I'd have to verify if GlobalSign is a valid Authenticode
    > certificate
    > > provider, with installed roots.
    >
    > For KMCS, it doesn't matter. There is only one valid root
    > provider (Microsoft), and you must embed a cross-certificate
    > that chains from your provider to Microsoft.
    >
    > --
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online
    > at http://www.osronline.com/page.cfm?name=ListServer
    >
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,002
    Jan Bottorff wrote:
    > It seems like you're both agreeing and disagreeing with what I said in two
    > different paragraphs.
    >

    Probably. ;)

    > Your reply said "an x64 driver that is used by the boot loader must have the
    > signature embedded in the driver binary" and then your reply also said "The
    > x64 KMCS signature check happens every single time the driver is loaded".
    >

    Yes. When a driver loads on x64, if the binary does not have an
    embedded signature, the system will go searching for the .cat file. The
    reason they want boot-start binaries to have an embedded signature is to
    avoid the performance hit of searching for the .cat file.

    > My understanding is (unless you are in a special debugging/test mode) that
    > EVERY x64 driver on Vista/W2K8 will need an embedded signature, no matter
    > when it starts. Are you saying your believe a non-boot start x64 driver on
    > Vista/W2K8 does not need an embedded signature, or am misinterpreting what
    > your saying?
    >

    That is what I am saying, yes. It's more than a belief -- I know this
    for a fact, because I've done it. I sign the .cat file, and Vista x64
    runs it. The Kernel Mode Code Signing white paper (kmsigning.doc) even
    says this.

    > My overall point was that "signed driver" has multiple meanings, and the
    > correct kind of signature is required for a desired purpose. Putting a KMCS
    > signature on a driver will not make it show up as "signed" in device
    > manager, or make it install silently.

    Correct.

    > As I remember, a correctly signed
    > .cat, and unsigned binary (on x64 Vista/W2K8) will show up as signed in
    > device manager, but when the OS tries to start the driver, it fails with an
    > error that says the binary is not signed.
    >

    Nope, this is not the case. As long as the binary is unchanged from the
    one in the .cat file (they do a checksum), the binary does not have to
    be signed as long as the .cat file is.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    Tim's right. You REALLY only NEED to sign the .SYS file for boot start drivers on x64. And you ALWAYS need to sign the .CAT file

    OTOH, it never HURTS to sign both. So, in trying to explain this to people, our message has been "just sign everything, all the time."

    And, you're completely right Jan: The whole KMCS/integrity thing is different from WHQL signing. A signature from WHQL will be sufficient for both install and KMCS purposes, but a 3rd party authenticode signature may be only sufficient for KMCS purposes (depending on the device category).

    It's all so confusing. It makes me happy I don't do "real" installation procedures for products,

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > It's all so confusing. It makes me happy I don't do "real"
    > installation procedures for products,

    Does anybody know if there is a COMPLETE and ACCURATE document/web page that
    explains the EXACT requirements for signatures as related to drivers, across
    all flavors of Windows and all scenarios? Probably some sort of flowchart,
    that spells out little details like W2K3 must have WHQL signatures
    (certified or unclassified) unless it's a device in a custom class and you
    install the correct certs in the correct cert store, except if you're doing
    unattended OS install in which case any class can install without signatures
    (I think). There are little fragments of documentation that mention these
    things, but know of no place that brings it all together.

    Even though I've spent literally a month or two of the last few years
    dealing with these kinds of issues, apparently I still am learning new
    stuff. The ability of the kernel to use the .cat signature to validate an
    unsigned binary of a reinstanciated device on x64 Vista/W2K is a little
    shift in my understanding. It sounds like for optimal performance though, it
    still might be better to put a signature on the binary, or do non-boot x64
    driver loads always search for the .cat?

    It's very difficult for a driver developer to PLAN what would be needed to
    give specific install behaviors on specific Windows versions.

    Jan
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    So, can anyone explain why using "CopyINF" fails on Vista 64 if the driver to be copied does not have a signed .SYS file?

    Driver A copies driver B. Driver B can be installed by Found New Hardware Wizard and by difx, and used in the usual way, on Vista 64 without any problems. What is different about CopyINF?

    Tim Green.


    -----Original Message-----
    From: xxxxx@lists.osr.com on behalf of xxxxx@osr.com
    Sent: Tue 17/03/2009 20:11
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] Vista 64-bit code signing: "windows can't verify the publisher of this driver"

    Tim's right. You REALLY only NEED to sign the .SYS file for boot start drivers on x64. And you ALWAYS need to sign the .CAT file

    OTOH, it never HURTS to sign both. So, in trying to explain this to people, our message has been "just sign everything, all the time."

    And, you're completely right Jan: The whole KMCS/integrity thing is different from WHQL signing. A signature from WHQL will be sufficient for both install and KMCS purposes, but a 3rd party authenticode signature may be only sufficient for KMCS purposes (depending on the device category).

    It's all so confusing. It makes me happy I don't do "real" installation procedures for products,

    Peter
    OSR



    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    <QUOTE>
    Does anybody know if there is a COMPLETE and ACCURATE document/web page that explains the EXACT requirements for signatures as related to drivers, across all flavors of Windows and all scenarios?
    </QUOTE>

    Nobody that I know, to be honest. But it would make a great document.

    The problem is that these two different signing policies (signing's effect on the installation dialog -- generating one or more different user warnings -- versus Kernel Mode Code Signing for x64) are designed and administered by two entirely separate groups at Microsoft.

    We need somebody who has a comprehensive understanding of these processes to be able to create that document. OR somebody who cares enough to do the research/experimentation.

    If somebody DOES write it up, I know we'll be happy to put it in The NT Insider for the world to read and understand.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > The problem is that these two different signing policies
    > (signing's effect on the installation dialog -- generating
    > one or more different user warnings -- versus Kernel Mode
    > Code Signing for x64) are designed and administered by two
    > entirely separate groups at Microsoft.

    That's a great reminder. I sometimes think there is a single Windows god at
    Microsoft that has everything totally coordinated. And then scratch my head
    when it's not.

    Jan
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    IIRC, boot start drivers must have an embedded signature, and drivers that start later can use either an embedded signature or a .cat signature.

    (For in-box things, a .cat is preferred where possible so that the large cert blobs aren't duplicated for every single PE image, but rather are stored in a more efficient, centralized location. The sig blob embedded in a binary with the certs included might be on the order of 10k per binary, whereas a .cat doesn't need to duplicate the certificate parts (largest by far) over and over.

    For example, win32k.sys on my Vista SP1 x64 box has a .cat signature and not an embedded one (no security directory in the PE header). However, ntfs.sys has a security directory with the certificate blob + signature.

    - S

    -----Original Message-----
    From: Jan Bottorff <xxxxx@pmatrix.com>
    Sent: Tuesday, March 17, 2009 11:55
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: RE: [ntdev] Vista 64-bit code signing: "windows can't verify the publisher of this driver"


    Tim,

    It seems like you're both agreeing and disagreeing with what I said in two
    different paragraphs.

    Your reply said "an x64 driver that is used by the boot loader must have the
    signature embedded in the driver binary" and then your reply also said "The
    x64 KMCS signature check happens every single time the driver is loaded".

    My understanding is (unless you are in a special debugging/test mode) that
    EVERY x64 driver on Vista/W2K8 will need an embedded signature, no matter
    when it starts. Are you saying your believe a non-boot start x64 driver on
    Vista/W2K8 does not need an embedded signature, or am misinterpreting what
    your saying?

    Yes, I was not totally clear about the validity of a GlobalSign certificate,
    and yes there would need to be a valid certificate chain to a valid root,
    and that requires adding the correct cross-certificate. I always have used
    VeriSign certificates, so don't have any personal knowledge about using
    GlobalSign certificates.

    My overall point was that "signed driver" has multiple meanings, and the
    correct kind of signature is required for a desired purpose. Putting a KMCS
    signature on a driver will not make it show up as "signed" in device
    manager, or make it install silently. As I remember, a correctly signed
    .cat, and unsigned binary (on x64 Vista/W2K8) will show up as signed in
    device manager, but when the OS tries to start the driver, it fails with an
    error that says the binary is not signed.

    Jan


    > -----Original Message-----
    > From: xxxxx@lists.osr.com
    > [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
    > Sent: Tuesday, March 17, 2009 9:49 AM
    > To: Windows System Software Devs Interest List
    > Subject: Re: [ntdev] Vista 64-bit code signing: "windows
    > can't verify the publisher of this driver"
    >
    > Jan Bottorff wrote:
    > > Lert me ask a few questions. Are you signing the .sys binary or the
    > > .cat fle? Or both? They are totally different signatures.
    > >
    > > During driver installation, you need the .cat signed. On Vista/W2K8
    > > x64, you also need the binary signed.
    >
    > This is not quite correct. The .cat signature is all you
    > need in every case except one: an x64 driver that is used by
    > the boot loader must have the signature embedded in the
    > driver binary. That's the only exception. For all other
    > drivers, the .cat signature is sufficient.
    >
    >
    > > On Vista x64 the expected behaivor would be: the first time you
    > > install a driver with your Authenticode signature a dialog
    > will come
    > > up, and it will have an option to "always trust drivers
    > from xxx". To
    > > prevent this, you need either a) a WHQL signature, b) the the
    > > Authenticode cerificate already installed as I believe a trusted
    > > publisher. I belive you can get option B to happen via a
    > network doman
    > > group policy, so all machines that are domain members will trust
    > > drivers from that company.You also can add the publisher
    > certificate
    > > on first install, and then laters installs of that device should be
    > > silent.
    >
    > You're talking about the "install time" behavior on all
    > systems, not the
    > x64 KMCS behavior. The x64 KMCS signature check happens
    > every single time the driver is loaded. There are no easy
    > policies to override that. You can either (1) attach a
    > kernel debugger, (2) press F8 at boot time to turn it off, or
    > (3) enable /testsign and install your certificate as a trusted root.
    >
    >
    > > I'd have to verify if GlobalSign is a valid Authenticode
    > certificate
    > > provider, with installed roots.
    >
    > For KMCS, it doesn't matter. There is only one valid root
    > provider (Microsoft), and you must embed a cross-certificate
    > that chains from your provider to Microsoft.
    >
    > --
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online
    > at http://www.osronline.com/page.cfm?name=ListServer
    >


    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    It does waste space though on the whole. Given that all binaries shipping with the OS are signed, I suspect that the savings for using cat files are in the hundreds of megabytes given the size of the cert part of the blob.

    Granted, for the third party case, the ratio of binaries to unique certs is much higher. But there is a sensible reason for the idea.

    - S

    -----Original Message-----
    From: xxxxx@osr.com <xxxxx@osr.com>
    Sent: Tuesday, March 17, 2009 13:10
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Subject: RE:[ntdev] Vista 64-bit code signing: "windows can't verify the publisher of this driver"


    Tim's right. You REALLY only NEED to sign the .SYS file for boot start drivers on x64. And you ALWAYS need to sign the .CAT file

    OTOH, it never HURTS to sign both. So, in trying to explain this to people, our message has been "just sign everything, all the time."

    And, you're completely right Jan: The whole KMCS/integrity thing is different from WHQL signing. A signature from WHQL will be sufficient for both install and KMCS purposes, but a 3rd party authenticode signature may be only sufficient for KMCS purposes (depending on the device category).

    It's all so confusing. It makes me happy I don't do "real" installation procedures for products,

    Peter
    OSR



    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • annie_liannie_li Member Posts: 57
    I signed driver referring to "Kernel-Mode Code Signing Walkthrough",
    http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx, it
    works fine under Srv2008/Vista 64bits.
    Hope following tips can help you.

    * make sure your OS time is correct when you sign your cat file.
    * use bcdedit to set TESTSIGNING on in your 64bit system.
    * Installing your certificate in your system, for example:
    certmgr.exe /add aaa.cer /s /r localMachine root
    certmgr.exe /add aaa.cer /s /r localMachine trustedpublisher

    Thanks
    Annie
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Tim Green wrote:
    >
    > So, can anyone explain why using "CopyINF" fails on Vista 64 if the
    > driver to be copied does not have a signed .SYS file?
    >
    > Driver A copies driver B. Driver B can be installed by Found New
    > Hardware Wizard and by difx, and used in the usual way, on Vista 64
    > without any problems. What is different about CopyINF?
    >
    I have also seen this behaviour.

    It looked to me as though CopyINF was not copying and installing the
    catalog file associated with the referenced INF file. Adding a CopyINF
    directive to DriverA.inf referencing DriverB.inf, meant that when
    installing DriverA DriverB.inf and all files referenced by CopyFiles
    directives in DriverB.inf were copied correctly, but it looked like the
    catlog referenced by the CatalogFile directive in DriverB.inf was not
    copied /installed/registered. Therefore when the system subsequently
    tries to install DriverB on a device it can't find the associated
    catalog file and treats the driver as unsigned. If DriverB's binaries
    are signed directly it doesn't need to check the catalog file referenced
    in DriverB.inf and therefore it works...

    I'd say it is a bug in the implementation of CopyINF.

    Best regards,


    Andrew

    --
    Andrew Lee Solarflare Communications
    mailto:xxxxx@solarflare.com http://www.solarflare.com/
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Wanted to answer some questions raised in this thread. All of the information in this pertains to Vista and greater. Older versions of the OS do not behave this way.

    First, there is a cross-certificate available for GlobalSign. If the catalog file is being properly signed and cross-signed with the GlocalSign cert and cross-cert, there should not be any issues with Kernel mode code signing (KMCS).

    Next, some info about KMCS: The KMCS checks are done when the driver is loaded. Microsoft uses the term "embedded signing" to mean that the driver binaries are signed directly - as opposed to "catalog signing". KMCS does not REQUIRE "embedded signing", however there is a *significant* performance penalty at boot time if boot drivers do not have "embedded signing" - this is true for both X86 and x64 systems. Therefore, Microsoft strongly recommends that drivers have "embedded signing" with certificate and cross-certificate on all drivers. WHQL does not provide embedded signing of driver packages - they only provide a signature of the catalog file. So embedded signing must be done by the customer - I believe WHQL has a Logo test in place to validate this.

    For driver installation:
    1. Driver installation ONLY uses the catalog file. Embedded signatures will not affect the behavior of the pop-ups.
    2. Cross-certificates are REQUIRED for KMCS signing, but don't mean anything for driver installation. Cross signing will not affect the behavior of the pop-ups.
    3. An unsigned driver OR a driver that is signed with a certificate that does not "root" to a certificate in the local computer Trusted Root store will result in the dialog with an ERROR that the driver is not signed.
    4. A driver that is signed with a certificate that "roots" to a certificate in the local computer Trusted Root store (one from an approved CA) will result in the "unknown publisher" WARNING dialog, unless the signing cert used to sign the catalog is in the local computer Trusted Publisher store.
    5. You will not see a dialog during installation if:
    a. The catalog file has a Windows signature (THis is for ALL OS versions)
    b. The catalog file has a WHQL signature (This is for ALL OS versions)
    c. The catalog file is signed with a certificate that was issued by a Trusted Root CA AND the certificate is in the local machine Trusted Publisher store. (This is for VISTA and newer.)

    Hope this helps. As I said, this is Vista and newer. Prior to Vista, there was no KMCS in the code, so the cross-certificates don't mean ANYTHING prior to Vista.
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >During driver installation, you need the .cat signed. On Vista/W2K8 x64, you also need the binary
    >signed.

    Not so.

    There are 2 kinds of signing:

    a) KMCS:
    - Vista+ x64 only
    - you can sign the binary OR the .cat
    - checked _on load_, the driver will not be loaded if there are signature issues
    - to obtain this, you must have a code signing cert from Verisign or such and apply this cert

    b) WHQL signing
    - any Windows from w2k up
    - you must sign the .cat
    - check _on PnP install_ (during INF file execution)
    - lack of signature causes the extra message boxes during install and also Device Manager telling that the driver is not signed
    - to obtain this, the driver must be tested by DTM and then a WHQL submission must be done to MS

    Surely the OP has KMCS OK, and issues with lack of WHQL signing.

    --
    Maxim S. Shatskih
    Windows DDK MVP
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > My understanding is (unless you are in a special debugging/test mode) that
    > EVERY x64 driver on Vista/W2K8 will need an embedded signature, no matter
    > when it starts.

    The signature can be in a .cat, except for boot-start drivers.

    --
    Maxim S. Shatskih
    Windows DDK MVP
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    Jennifer,

    Very helpful post, thanks.

    A couple of questions:

    <QUOTE>
    KMCS does not REQUIRE "embedded signing", however there is a *significant* performance penalty at boot time if boot drivers do not have "embedded signing" - this is true for both X86 and x64 systems
    </QUOTE>

    There is a *significant* performance penalty on x86 systems if boot-start drivers are not "embedded signed"?? REALLY? This is the first time I've heard of this... why does the OS check for signatures at boot on x86, when it just ignores them? What am I missing?

    <QUOTE>
    WHQL does not provide embedded signing of driver packages - they only provide a signature of the catalog file. So embedded signing must be done by the customer. I believe WHQL has a Logo test in place to validate this.
    </QUOTE>

    Hmmm... (a) Why in the world doesn't WHQL sign the .SYS file? Wouldn't that be a good thing? (b) You're saying that for a driver to be logo'ed, the .SYS file MUST be signed? THAT's something I haven't heard before and is very interesting. This would mean that to logo my driver, I have to figure out the driver signing process in any case... I can't just submit my driver to WHQL and "let them take care of it."

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > <QUOTE>
    > KMCS does not REQUIRE "embedded signing", however there is a *significant* performance penalty
    at boot time if boot drivers do not have "embedded signing" - this is true for both X86 and x64 systems
    > </QUOTE>

    I don't know who is right, but this would seem to contradict what the kmcs_walkthrough.doc reports:

    >• Boot-start drivers.
    >In the special case of boot-start drivers—drivers that are loaded by the Windows Vista operating
    >system loader—publishers must use an SPC to embedded-sign the driver binary image file. This
    >requirement ensures optimal system boot performance.

    mm





    xxxxx@osr.com wrote:
    > Jennifer,
    >
    > Very helpful post, thanks.
    >
    > A couple of questions:
    >
    > <QUOTE>
    > KMCS does not REQUIRE "embedded signing", however there is a *significant* performance penalty at boot time if boot drivers do not have "embedded signing" - this is true for both X86 and x64 systems
    > </QUOTE>
    >
    > There is a *significant* performance penalty on x86 systems if boot-start drivers are not "embedded signed"?? REALLY? This is the first time I've heard of this... why does the OS check for signatures at boot on x86, when it just ignores them? What am I missing?
    >
    > <QUOTE>
    > WHQL does not provide embedded signing of driver packages - they only provide a signature of the catalog file. So embedded signing must be done by the customer. I believe WHQL has a Logo test in place to validate this.
    > </QUOTE>
    >
    > Hmmm... (a) Why in the world doesn't WHQL sign the .SYS file? Wouldn't that be a good thing? (b) You're saying that for a driver to be logo'ed, the .SYS file MUST be signed? THAT's something I haven't heard before and is very interesting. This would mean that to logo my driver, I have to figure out the driver signing process in any case... I can't just submit my driver to WHQL and "let them take care of it."
    >
    > Peter
    > OSR
    >
    >
    >
  • jpeskinjpeskin Member Posts: 4
    First, thanks everybody for your input! I guess this is a topic of interest for many. To answer some questons:

    -This is not a boot start driver
    -I have signed ONLY the .cat file, and not the individual binaries.
    -This question is not about KMCS, because the kernel appears to accept my signatures, and the drivers load and execute just fine. This question is only about installation popups
    -This question is only about installation on a machine whose certificate store has not been modified in any way from factory-fresh Vista install.

    Jennifer: your post was very informative. I have a few clarification questions:

    > 4. A driver that is signed with a certificate that "roots" to a certificate in
    > the local computer Trusted Root store (one from an approved CA) will result in
    > the "unknown publisher" WARNING dialog, unless the signing cert used to sign the
    > catalog is in the local computer Trusted Publisher store.

    This appears to be my exact situation. My certificate roots to a Global Sign Root CA. My test machines have no certificates in the Trusted Publisher store.

    QUESTION 1: Is this the WARNING dialog you are referring to?:
    "Windows can't verify the publisher of this drivers software"
    See details... "The driver software you're attempting to install does not have a valid digital signature that verifies who published it....... ".

    This statement is confusing/misleading, because the GlobalSign certificate chain does verify who published the software. It does not necessarily mean that Microsoft has done any WHQL testing, and the warning message should state that the quality of the drivers can't be verified.

    QUESTION 2: Under the Driver tab, it says "Digital Signer: Not digitally signed"
    Is this because the driver is not Windows/WHQL signed? Or is there a problem with my .cat signature?

    QUESTION 3: Under the Driver tab... Driver details..., each file (including the WdfCoInstaller01007.dll) says "Digital Signer: Not digitally signed".
    Is this because the driver is not Windows/WHQL signed? Or will this go away if I just sign each binary with my signature?

    Thanks,
    Jonah
  • jpeskinjpeskin Member Posts: 4
    >> It's all so confusing. It makes me happy I don't do "real" installation
    >> procedures for products,
    >>
    >> Peter
    >> OSR

    Peter, would you mind giving a brief description of the installation procedure that you prefer? (with a focus on: XP, Vista, Vista x64)

    Prior to the Vista, I was inclined to manually copy all driver files to the proper Windows system directories (\windows\inf, \windows\system32\drivers, \windows\system32). When the USB device is plugged in, if the user selects the option of "Automatically find the drivers", both XP and Vista would discover them if the inf was written properly.

    Is that the process you refer to? Or is it something else, such as using DPInst or IFxApp, or DevCon, or other?

    Thanks,
    Jonah
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,251
    <QUOTE>
    >> It's all so confusing. It makes me happy I don't do "real" installation
    >> procedures for products,
    >>
    >> Peter
    >> OSR

    Peter, would you mind giving a brief description of the installation procedure
    that you prefer? (with a focus on: XP, Vista, Vista x64)
    </QUOTE>

    Aside from the smallest, hacked-up, engineering-level, crappy minimum necessary to get a driver installed for testing, I don't do any installation procedures at all. So, for USB let's say, I hack together some re-used junky .INF file, copy it to c:\Junk along with the .sys file, and plug the device in... then point the installer to the directory.

    Ugly, but my only need is to get things installed for development and testing.

    I also use DevCon a fair bit... one of the world's greatest utilities, I think.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • David_R._CattleyDavid_R._Cattley Member - All Emails Posts: 2,112
    <petergv>
    DevCon a fair bit... one of the world's greatest utilities
    </petergv>

    Hear Hear!

    Too bad the INetCfg swiss-army-knife equivalent SNETCFG.EXE got retired in
    favor of BindView. Between devcon and snetcfg I have been able to avoid
    creating installers of any sort for almost all development work. And don't
    forget SC.EXE to pull out those left-over PnP driver service entries!

    There is something to be said for "simply works".

    And hardly ugly....

    -dave

    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    Sent: Friday, March 20, 2009 10:48 AM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] Vista 64-bit code signing: "windows can't verify the
    publisher of this driver"

    <QUOTE>
    >> It's all so confusing. It makes me happy I don't do "real" installation
    >> procedures for products,
    >>
    >> Peter
    >> OSR

    Peter, would you mind giving a brief description of the installation
    procedure
    that you prefer? (with a focus on: XP, Vista, Vista x64)
    </QUOTE>

    Aside from the smallest, hacked-up, engineering-level, crappy minimum
    necessary to get a driver installed for testing, I don't do any installation
    procedures at all. So, for USB let's say, I hack together some re-used
    junky .INF file, copy it to c:\Junk along with the .sys file, and plug the
    device in... then point the installer to the directory.

    Ugly, but my only need is to get things installed for development and
    testing.

    I also use DevCon a fair bit... one of the world's greatest utilities, I
    think.

    Peter
    OSR


    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Ugly? No, that would be a setup driven by, say, xml configuration files.

    mm

    David R. Cattley wrote:
    > <petergv>
    > DevCon a fair bit... one of the world's greatest utilities
    > </petergv>
    >
    > Hear Hear!
    >
    > Too bad the INetCfg swiss-army-knife equivalent SNETCFG.EXE got retired in
    > favor of BindView. Between devcon and snetcfg I have been able to avoid
    > creating installers of any sort for almost all development work. And don't
    > forget SC.EXE to pull out those left-over PnP driver service entries!
    >
    > There is something to be said for "simply works".
    >
    > And hardly ugly....
    >
    > -dave
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com
    > [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    > Sent: Friday, March 20, 2009 10:48 AM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] Vista 64-bit code signing: "windows can't verify the
    > publisher of this driver"
    >
    > <QUOTE>
    >>> It's all so confusing. It makes me happy I don't do "real" installation
    >>> procedures for products,
    >>>
    >>> Peter
    >>> OSR
    >
    > Peter, would you mind giving a brief description of the installation
    > procedure
    > that you prefer? (with a focus on: XP, Vista, Vista x64)
    > </QUOTE>
    >
    > Aside from the smallest, hacked-up, engineering-level, crappy minimum
    > necessary to get a driver installed for testing, I don't do any installation
    > procedures at all. So, for USB let's say, I hack together some re-used
    > junky .INF file, copy it to c:\Junk along with the .sys file, and plug the
    > device in... then point the installer to the directory.
    >
    > Ugly, but my only need is to get things installed for development and
    > testing.
    >
    > I also use DevCon a fair bit... one of the world's greatest utilities, I
    > think.
    >
    > Peter
    > OSR
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    To answer Peter's questions: Yes, it checks for signatures on x86 drivers at boot, and then ignores them if they are missing. Can't say why - but that is the behavior. We've spent a lot of time with the OEMs making sure they have signatures on all their boot loaded drivers.

    WHQL is checking for the signature on the .sys file precisely because of the boot performance issue. (At least I *think* they added this test - I'm not as close to this issue as I use to be :-) Why don't they sign it themselves? They don't have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.

    MM: No contradiction. The KMCS walkthrough says "This requirement ensures optimal system boot performance." Not, "This is required to boot."


    Jonah:
    1. I think the dialog you are seeing is the "unsigned" Error dialog, not the warning dialog. When I look in the local computer Trusted Root store on my Vista machine, I don't see a cert from Global Sign. Use MMC.exe - install the certificates plug in for the Computer Account - it will show up as Local Computer. And then look in the Trusted Root Certificate Authorities folder, certificates. Is the certificate there that your signing cert has as it's root? (To find that, right click on a catalog file or .sys file that you have signed, go to properties, select the Digital Signatures Tab. Select the item from the signature list and click details. On the Digital signatures details dialog, do you see a message that says "A certificate chain processed, but terminated in a root certificate that is not trusted by the trust provider"? Alternative, what do you get if you do:
    "signtool verify /v /pa <your catalog file>.cat"

    2. It should be looking at the signature on the catalog file and showing the signature, IF it is a "valid" signature. If you had a problem with #1, you'll have a problem here.

    3. That is a bug in that dialog. You should ignore it.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Jennifer:

    I'm confused - it uses the words 'must' and 'requirement.'

    >In the special case of boot-start drivers—drivers that are loaded by the Windows Vista operating
    >system loader—publishers MUST use an SPC to embedded-sign the driver binary image file. This
    >REQUIREMENT ensures optimal system boot performance.

    mm

    xxxxx@microsoft.com wrote:
    > To answer Peter's questions: Yes, it checks for signatures on x86 drivers at boot, and then ignores them if they are missing. Can't say why - but that is the behavior. We've spent a lot of time with the OEMs making sure they have signatures on all their boot loaded drivers.
    >
    > WHQL is checking for the signature on the .sys file precisely because of the boot performance issue. (At least I *think* they added this test - I'm not as close to this issue as I use to be :-) Why don't they sign it themselves? They don't have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.
    >
    > MM: No contradiction. The KMCS walkthrough says "This requirement ensures optimal system boot performance." Not, "This is required to boot."
    >
    >
    > Jonah:
    > 1. I think the dialog you are seeing is the "unsigned" Error dialog, not the warning dialog. When I look in the local computer Trusted Root store on my Vista machine, I don't see a cert from Global Sign. Use MMC.exe - install the certificates plug in for the Computer Account - it will show up as Local Computer. And then look in the Trusted Root Certificate Authorities folder, certificates. Is the certificate there that your signing cert has as it's root? (To find that, right click on a catalog file or .sys file that you have signed, go to properties, select the Digital Signatures Tab. Select the item from the signature list and click details. On the Digital signatures details dialog, do you see a message that says "A certificate chain processed, but terminated in a root certificate that is not trusted by the trust provider"? Alternative, what do you get if you do:
    > "signtool verify /v /pa <your catalog file>.cat"
    >
    > 2. It should be looking at the signature on the catalog file and showing the signature, IF it is a "valid" signature. If you had a problem with #1, you'll have a problem here.
    >
    > 3. That is a bug in that dialog. You should ignore it.
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    MM - think of this the way you think of a Logo requirement.....
  • jpeskinjpeskin Member Posts: 4
    Jennifer, thanks again for your help! But please note:

    >> Jonah:
    >> 1. I think the dialog you are seeing is the "unsigned" Error dialog, not the
    >> warning dialog. When I look in the local computer Trusted Root store on my
    >> Vista machine, I don't see a cert from Global Sign. Use MMC.exe - install the
    >> certificates plug in for the Computer Account - it will show up as Local
    >> Computer. And then look in the Trusted Root Certificate Authorities folder,
    >> certificates. Is the certificate there that your signing cert has as it's root?

    Yes, there is a "GlobalSign", and two "GlobalSign Root CA" certificates, all 3 of those are under Trusted Root Certificate Authorities on both my XP Pro machine and Vista64 machine.

    >> (To find that, right click on a catalog file or .sys file that you have signed,
    >> go to properties, select the Digital Signatures Tab. Select the item from the
    >> signature list and click details. On the Digital signatures details dialog, do
    >> you see a message that says "A certificate chain processed, but terminated in a
    >> root certificate that is not trusted by the trust provider"?

    On the .cat file's "Digital Signatures" tab, clicking on the item in the Signature List, it says "This digital signature is OK". No error message like you state on any of the sub-dialogs.

    >> Alternative, what
    >> do you get if you do:
    >> "signtool verify /v /pa <your catalog file>.cat"

    Number of files successfully Verified: 1
    Number of warnings: 0
    Number of errors: 0

    Despite all this, during install, I still see what you believe is an Error message (as opposed to Warning message). If you could clarify exactly what the Error message and Warning message each say, that would be helpful.

    Thanks!
    Jonah
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA