locked
HTTP 403.13 during SCCM client push RRS feed

  • Question

  • We have multiple forest connected to a shared SCCM 2012 R2 site.

    The site is in SSL only mode

    With one forest we have problems pushing clients from SCCM.

    Install works fine but soon as the client connects to the MP we get HTTP 403.13 failures.

    RootCA certs have been added to SCCM

    RootCA certs of the remote forest are added both sided to trusted root CA

    CRL can be checked both sides using IE.

    Still IIS logs on the MP show

    2014-08-07 08:14:57 managementpointip CCM_POST /ccm_system_windowsauth/request - 443 - hostip ccmhttp - 403 13 2148081683 34

    ccm messaging logs show

    Post to https://MPFQDN/ccm_system_windowsauth/request failed with 0x87d00231

    The following registry keys have been set to

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    ClientauthTrustmode REG_DWORD 2

    sendtrustedissuerlist REG_DWORD 0

    The strange thing is that one forest works and one not. Both are identical configured.

    Firewall ports are open.

    Thursday, August 7, 2014 9:08 AM

All replies

  • Thursday, August 7, 2014 9:22 AM
  • Hi Torsten,

    I have seen that article and yes it is CRL related. The thing is the MP is configured not to check the CRL.

    Now the client push seems to ignore that value. A local install can be configured with /nocrlcheck

    Still it worries me that the CRL can be accessed by the MP using a browser on the MP.


    SSL Certificate bindings:
    -------------------------

        IP:port                      : 0.0.0.0:443
        Certificate Hash             : 0317e07bab17b3f16502c1623778c1abeadbfd19
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : My
        Verify Client Certificate Revocation : Disabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

        IP:port                      : 0.0.0.0:8531
        Certificate Hash             : 0317e07bab17b3f16502c1623778c1abeadbfd19
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : My
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

     

    Thursday, August 7, 2014 10:56 AM
  • Those are two separate things. From what you're showing you've disabled CRL checking in IIS (that's not a Management Point thing) and that has nothing to do with /NoCRLCheck. That parameter makes sure that the client doesn't check the CRL when it communicates over HTTPS.

    To make it all work as it should you've got to make sure that both, the client and the server, are able to check the CRL. If that's all configured it shouldn't be necessary to create workarounds like disabling CRL checking on IIS.


    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Thursday, August 7, 2014 11:10 AM
  • Hi Peter,

    Thanks for your reply. Before changing the IIS on the MP to not check CRL both the manual install as the push install was failing.

    Now the manual install works but the push still fails.

    So you say to allow crl checking both ways?

    Thursday, August 7, 2014 11:58 AM
  • Then probably at that point both, your client and server, were not able to do any CRL checking. And you've workaround it by disabling CRL checking in IIS and telling the client to do the same by specifying /NoCRLCheck.

    Back to your question, yes, in the ideal world, both your client and server should be able to access the CRL.


    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Thursday, August 7, 2014 12:05 PM
  • Is there a way to disable crl checking in the push installation properties?
    Thursday, August 7, 2014 12:06 PM
  • It should be possible by using the (undocumented) property CCMHTTPSSTATE=31 (see also: http://blogs.technet.com/b/jchalfant/archive/2014/05/07/build-and-capture-in-https-only-configmgr-2012-r2-environment.aspx).

    Do keep in mind that if you're simply disabling CRL checking, you're actually working around the real problem.


    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Thursday, August 7, 2014 12:15 PM
  • Invalid argument '/NoCrlCheck' in the config file. Ignore it so that does not work for push install
    Thursday, August 7, 2014 12:18 PM
  • The CCMHTTPSSTATE=31 did not help the push install still fails

    ![LOG[[CCMSETUP] AsyncCallback(): -----------------------------------------------------------------]LOG]!><time="11:28:10.865-120" date="08-07-2014" component="ccmsetup" context="" type="3" thread="336" file="httphelper.cpp:698">
    <![LOG[[CCMSETUP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered]LOG]!><time="11:28:10.865-120" date="08-07-2014" component="ccmsetup" context="" type="3" thread="336" file="httphelper.cpp:699">
    <![LOG[[CCMSETUP]                : dwStatusInformationLength is 4
    ]LOG]!><time="11:28:10.865-120" date="08-07-2014" component="ccmsetup" context="" type="3" thread="336" file="httphelper.cpp:700">
    <![LOG[[CCMSETUP]                : *lpvStatusInformation is 0x9
    ]LOG]!><time="11:28:10.865-120" date="08-07-2014" component="ccmsetup" context="" type="3" thread="336" file="httphelper.cpp:701">
    <![LOG[[CCMSETUP]            : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set
    ]LOG]!><time="11:28:10.865-120" date="08-07-2014" component="ccmsetup" context="" type="3" thread="336" file="httphelper.cpp:705">
    <![LOG[[CCMSETUP]            : WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set
    ]LOG]!><time="11:28:10.865-120" date="08-07-2014" component="ccmsetup" context="" type="3" thread="336" file="httphelper.cpp:717">

    • Edited by LA1976 Thursday, August 7, 2014 12:35 PM
    Thursday, August 7, 2014 12:33 PM
  • Did you check the client log files to see if it truly used that parameter (CertificateMaintenance.log, ClientLocation.log, CcmMessaging.log)?

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Thursday, August 7, 2014 12:38 PM
  • In the ccmsetup.log it shows the parameter


    <![LOG[MSI properties:    INSTALL="ALL" SMSSITECODE="NET" DNSSUFFIX="suffix" SMSMP="smsmp" CCMHTTPSSTATE="31" CCMHTTPPORT="80" CCMHTTPSPORT="443" "

    Thursday, August 7, 2014 12:51 PM
  • It seems that push installs ignore crlcheck disable settings even the option 31. That brings me almost the the conclusion that push installs are not compatible with native mode only. CRL is available both sides still it fails so you can also name this a bug. Manual install still works perhaps I need to call MS support and have it fixed.
    Thursday, August 7, 2014 2:57 PM
  • Did you try adding /nocrlcheck to the push install properties in the site settings? (It's not clear from the threads above whether you did or did not). As of R2, you should be able to add it.

    Why not use a different deployment method though like a startup script?


    Jason | http://blog.configmgrftw.com

    Thursday, August 7, 2014 3:53 PM
  • yes the logs say invalid argument as posted earlier. You mention it should be possible ... How?
    Thursday, August 7, 2014 5:23 PM
  • In R2 (I think it was R2) they added the ability to add ccmsetup parameters. This could be limited to a certain parameters though.

    Ultimately though, why not use a startup script?


    Jason | http://blog.configmgrftw.com

    Thursday, August 7, 2014 6:02 PM
  • I need to update this forest without rebooting the servers in it. A startup script cannot be used.I need to have push installation fixed.
    Friday, August 8, 2014 4:04 AM
  • To provide some more details. I ran the command certutil -verify -urlfetch "path to cert" on both sides and both sides give the result

    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.

    So the certs are ok, it does select a cert CRL's are OK and still it fails.

    Friday, August 8, 2014 6:15 AM
  • Just to be sure, did you run the command on the client for the server certificate and on the server for the client certificate?

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Friday, August 8, 2014 6:18 AM
  • Not every problem can be solved here in the forums, especially when they are happening ín a complex environment. I'd use Wireshark or Netmon next; they *might* show something useful.

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, August 8, 2014 6:20 AM
  • Yes on the client I validated the server cert and the server the client cert.
    Friday, August 8, 2014 6:23 AM
  • I post this also as there are many others that face this issue. Clearly this must be a bug. I will report a ticket to MS support and update this post as soon as I have more information.
    Friday, August 8, 2014 6:25 AM
  • Good idea. Personally, I would ask them to look at the 403.13 error and without disabling CRL checking. Let them look at the real problem and not work around it.

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude


    Friday, August 8, 2014 6:27 AM
  • Then how about psexec or PowerShell remoting?

    Jason | http://blog.configmgrftw.com

    Friday, August 8, 2014 3:06 PM
  • That could be a last resort but it requires changes to the infrastructure.

    I prefer to have it fixed.

    I ticket is opened with MS support. I will update this ticket next week.

    Saturday, August 9, 2014 7:26 AM