locked
Using a thirdparty for SSL Cert for SCOM gateway RRS feed

  • Question

  • Hi,
      How does one go about getting a certificate for the MS and Gateway when an Enterprise and or Stand alone CA is not an option?  (I have federal regulations I have comply with preventing me from setting one up).
      I'm guessing using something like certreq.exe to build the CSR file, I just need to know how to setup the INF file to work with Entrust.  The documentation does state that ie VeriSign can be used but unlike IIS, Exchange, ect. I can not find anything built into SCOM to generate a CSR in the correct format.

    Thank You,
    Tim

    Thursday, June 4, 2009 5:21 PM

Answers

  • I want to say this is supported but to be honest we haven't had much luck with customers getting 3rd party certificates to work.  Below is sample INF that *should* give all of the certificate requirements we need.  Like you said, the certreq tool is the way to create the request file from the INF.

    Post back if this does not work out and hopefully someone can help troubleshoot.  Below is link to powershell script that helps diagnose certificate issues, and could help with any troubleshooting by quickly identifying common issues.

    ;---------------CertificateRequestTemplate.inf--------------
    [NewRequest]
    Subject="CN=<FQDN of gateway>"
    Exportable=TRUE
    KeyLength=1024
    KeySpec=1
    KeyUsage=0xa0
    MachineKeySet=TRUE
    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.1
    OID=1.3.6.1.5.5.7.3.2


    http://blogs.technet.com/momteam/archive/2009/01/23/troubleshooting-ops-mgr-certificate-issues-with-powershell.aspx
    • Proposed as answer by S. Halsey Thursday, June 4, 2009 6:30 PM
    • Marked as answer by Rob Kuehfus Friday, June 5, 2009 10:28 PM
    Thursday, June 4, 2009 6:17 PM
  • I was finally able to get a 3rd party cert to work on an agent in a workgroup DMZ, and on our management servers.  Apparently the thing I was missing was having the signed certificate and the request file in the same folder when running certreq -accept.  I never saw this documented anywhere, so hopefully this will serve that purpose.

    1. Used the following template:
    [Version]
    Signature= "$Windows NT$"
    [NewRequest]
    Subject = "CN=agent.contoso.com,OU=MyOU,O=MyOrg,L=MyCity,S=MyState,C=US"
    KeySpec= 1
    KeyLength = 1024
    KeyUsage = 0xa0
    ProviderName = "Microsoft RSA Schannel Cryptographic Provider"
    ProviderType = 12
    RequestType = PKCS10
    Exportable = TRUE
    MachineKeySet = TRUE
    UseExistingKeySet = FALSE
    [EnhancedKeyUsageExtension]
    OID = 1.3.6.1.5.5.7.3.1
    OID = 1.3.6.1.5.5.7.3.2

    2.  Copied the template to the server, updated the template with the correct common name.
    3.  Ran certreq -new template.inf mycert.req
    4.  Submitted mycert.req to the 3rd party CA
    5.  Received the signed certificate from the CA and copied to the requesting server
    6.  Placed the signed certificate from the CA in the same folder as the mycert.req request
    7.  Ran certreq -accept myserver.cer
    8.  Ran MomCertImport and choose the myserver certificate
    9.  Approved the agent in the SCOM console (it was manually installed previously)

    I also got the certs working with ACS, I believe this is pretty well documented already.

    • Marked as answer by Rob Kuehfus Sunday, July 26, 2009 10:21 PM
    Thursday, July 23, 2009 8:43 PM

All replies

  • I want to say this is supported but to be honest we haven't had much luck with customers getting 3rd party certificates to work.  Below is sample INF that *should* give all of the certificate requirements we need.  Like you said, the certreq tool is the way to create the request file from the INF.

    Post back if this does not work out and hopefully someone can help troubleshoot.  Below is link to powershell script that helps diagnose certificate issues, and could help with any troubleshooting by quickly identifying common issues.

    ;---------------CertificateRequestTemplate.inf--------------
    [NewRequest]
    Subject="CN=<FQDN of gateway>"
    Exportable=TRUE
    KeyLength=1024
    KeySpec=1
    KeyUsage=0xa0
    MachineKeySet=TRUE
    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.1
    OID=1.3.6.1.5.5.7.3.2


    http://blogs.technet.com/momteam/archive/2009/01/23/troubleshooting-ops-mgr-certificate-issues-with-powershell.aspx
    • Proposed as answer by S. Halsey Thursday, June 4, 2009 6:30 PM
    • Marked as answer by Rob Kuehfus Friday, June 5, 2009 10:28 PM
    Thursday, June 4, 2009 6:17 PM
  • We are struggling with this too, on agents though, not a gateway.  Our security group doesn't like having to mark private keys as exportable so we had to go 3rd party instead of using our Enterprise CA.

    The template Lincoln posted will get you a certificate, (once you add the OU, O, L, S, C pieces to the subject), however one big catch is that after importing the cert the intructions tell you to export to .pfx to be able to run MOMCertImport.  In my experience this will not work with certs from a 3rd party CA as the private key is not exportable.  You have to get the serial number from the cert and manually stick it in the registry HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Machine Settings (basically doing what MOMCertImport does).  You have to put the serial number in backwards too - be aware of that.
    Friday, June 19, 2009 11:12 PM
  • Thanks for the input Layne.  So it works now with the 3rd part cert?

    I'm suspicious that you might be able to get away without letting the private key be exportable, but only if you can get the certificate directly to the machine which needs it.  We "require" it to be exportable since common scenario is to copy it over to a workgroup machine which can't access the CA directly.  I have not tested this though.

    Regarding exporting to PFX, this isn't required as of SCOM 2007 SP1.  There is a command line option "/subjectname" which lets you specify the subjectname of the installed certificate you want to use.  Or you can run the tool with no command line parameters and it will open a window showing the localmachine\personal store, and you just click on the cert you want to use.

    Thanks,
    -Lincoln

    Saturday, June 20, 2009 1:02 AM
  • Thank you Lincoln for the information about the "/subjectname" option for MomCertImport.  I will be sure to try that when I install 10 agent certs in the next couple weeks.  I think you are right about not requiring keys to be exported as long as we can get the cert to the machine that needs it.  I will try to bring this up to our security team in the hopes of being able to use our Enterprise CA instead of buying certs 3rd party.  I will try to remember to post back my findings.

    Monday, June 22, 2009 3:10 PM
  • I got this from the mom listserv, hope it helps:

    The process we use as follows:
     
    We create an INF file  (MyServername.inf)  using the info below.   The OIDs at the bottom are specific to OpsMgr client and server communications.
     
    The RED section is unique to your environment and AD layout.  Not all of that line may be used.   The rest should not need to be changed.
     
    INF Contents
    ===========
     
    [Version]
    Signature="$Windows NT$
    [NewRequest]
    Subject = "CN=FQDN of server name,C=MyCountry,S=MyState,L=MyLocation/city,OU=(MY OU where server resides),O=(MY O - respective organization)"
    KeySpec = 1
    KeyLength = 1024
    Exportable = TRUE
    MachineKeySet = TRUE
    SMIME = False
    PrivateKeyArchive = FALSE
    UserProtected = FALSE
    UseExistingKeySet = FALSE
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    ProviderType = 12
    RequestType = PKCS10
    KeyUsage = 0xa0
    [EnhancedKeyUsageExtension]
    OID = 1.3.6.1.5.5.7.3.1
    OID = 1.3.6.1.5.5.7.3.2
     
    ==========================================
     
    Take the above contents and save via Notepad as  myservername.inf.
     
    On that server  complete the following command.
     
    certreq - new   myservername.inf  myservername.req
     
    This command should create the servername.req file.
     
    This file is send to the third party vendor to create the .cer file needed.
     
     
    Once received back,  copy the  servername.cer file to the target server  and complete the following:
    Note:   our vendor would send back  cert.cer files,  I renamed to my target server to help keep the gateways straight.
     
    certreq -accept  myservername.cer
     
     
    After it has been accepted,   can follow the gateway guidelines to export the pfx file and use the momcertimport tool and gateway commands to get communications going.
     
    I attached one reference guide for these.
     
    Hope this is helpful.

    One other note.........
     
    for each gateway,  I entered in the respective mgmt server FQDN name and ip in its  hosts file.
     
    has been working well for us.
     
    We are going to set up an internal CA within our network for those devices / applications needed this type of internal communications only.
     
    again,  hope this helps
     
    if have questions,  please send those back too.
    Thursday, July 2, 2009 2:56 PM
  • Well, more problems with a 3rd party cert.  After running MOMCertImport, we get the following event repeatedly in the Operations Manager Log.  We are trying to use certs obtained from Verizon Business (Cybertrust SureServer).

    Event Type: Error
    Event Source: OpsMgr Connector
    Event Category: None
    Event ID: 20077
    Date:  7/22/2009
    Time:  10:08:23 AM
    User:  N/A
    Computer: MASKED
    Description:
    The certificate specified in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings cannot be used for authentication, because the certificate cannot be queried for property information.  The specific error is 0x80092004(%3).
     
     This typically means that no private key was included with the certificate.  Please double-check to ensure the certificate contains a private key.

    If I run certreq -accept myservername.cer I get "Certificate Request Processor: Cannot find object or property. 0x80092004 (-2146885628)".

    So it looks like a private key is required?  I thought I was getting along well with this, but not anymore.

    Wednesday, July 22, 2009 5:19 PM
  • I was finally able to get a 3rd party cert to work on an agent in a workgroup DMZ, and on our management servers.  Apparently the thing I was missing was having the signed certificate and the request file in the same folder when running certreq -accept.  I never saw this documented anywhere, so hopefully this will serve that purpose.

    1. Used the following template:
    [Version]
    Signature= "$Windows NT$"
    [NewRequest]
    Subject = "CN=agent.contoso.com,OU=MyOU,O=MyOrg,L=MyCity,S=MyState,C=US"
    KeySpec= 1
    KeyLength = 1024
    KeyUsage = 0xa0
    ProviderName = "Microsoft RSA Schannel Cryptographic Provider"
    ProviderType = 12
    RequestType = PKCS10
    Exportable = TRUE
    MachineKeySet = TRUE
    UseExistingKeySet = FALSE
    [EnhancedKeyUsageExtension]
    OID = 1.3.6.1.5.5.7.3.1
    OID = 1.3.6.1.5.5.7.3.2

    2.  Copied the template to the server, updated the template with the correct common name.
    3.  Ran certreq -new template.inf mycert.req
    4.  Submitted mycert.req to the 3rd party CA
    5.  Received the signed certificate from the CA and copied to the requesting server
    6.  Placed the signed certificate from the CA in the same folder as the mycert.req request
    7.  Ran certreq -accept myserver.cer
    8.  Ran MomCertImport and choose the myserver certificate
    9.  Approved the agent in the SCOM console (it was manually installed previously)

    I also got the certs working with ACS, I believe this is pretty well documented already.

    • Marked as answer by Rob Kuehfus Sunday, July 26, 2009 10:21 PM
    Thursday, July 23, 2009 8:43 PM
  • Just wanted to post my experience with using this solution...

    This worked exceptionally well in a SCOM R2 environment.  The provided steps were spot on.  The cert checking powershell script that was linked above was invaluable as the cert vendor (Entrust) issued us several certificates that were missing certain key elements.

    An FYI also for anyone looking at this - if you use Entrust as a vendor make sure to use their 'Advantage' class cert.

    Thanks to everyone here for this information, at this time it's one of the few resources out there for this subject
    MS Skillset: SMS/SCCM, MOM/SCOM
    Friday, December 18, 2009 5:11 PM
  • Will,

    Which solution worked well for you?  The one just above your post? I am looking to do this in a customers SCOM R2 environment today to monitor DMZ servers and they dont have an internal PKI.  Do I need a third party cert on the Managmetn Server, Gateway and DMZ agents?

    Thasnk,
    Jay   
    Tuesday, February 2, 2010 5:06 PM
  • Hi there.  I'm the guy from the post above Will's.  :-)

    Where you need a certificate depends on how your environement is setup.  If you have an untrusted domain, and a Gateway machine in that domain, then you only need a certificate on the Gateway, and on the Management Server(s) the Gateway is configured to talk to.  The agents will use Kerberos to talk to the Gateway in their domain, and the Gateway will use the certificate to talk to the Management Server in the other domain.

    If you don't have a Gateway machine, for example if your DMZ is not a domain and just a collection of workgroup machines, you'll need a certificate on every Agent and the Management Server(s) they are reporting to.

    If you have an ACS Collector, you'll need a certificate on that too.  There's a couple extra steps to configure the cert for ACS.

    Hope this helps.
    Layne
    Tuesday, February 2, 2010 10:30 PM
  • Hi,

    Can anybody tell me I will need to request a certificate for each server?

    example:

    -1 certificate for the Management server

    -1 certificate for DMZ server 1

    -1 certificate for DMZ server 2

    -1 certificate for DMZ server 3


    How can each pc trust each other if their isn't a root trusted certificate?
    • Edited by Trail2012 Friday, December 14, 2012 11:21 AM
    Friday, December 14, 2012 11:09 AM
  • I have asked this on the general forum but suspect its better asked here on the relevant thread. I am getting mixed messages from people about how many certificates I need. If using an internal CA I would request a certificate for the Management Server AND the gateway individually from the CA (i.e. two certificates).

    When using an external I would presume I would repeat the INF process twice - once on the MS and once on the gateway. When filling in the INF on the gateway I would put the FQDN of the gateway and on the MS the INF would contain the FQDN of the MS. I would create two REQ files (one from each server) and sumbit two certificate requests from Entrust. However I am being told by someone else you just sumbit one request that contains the FQDN on the MS and then use that one certificate on both servers?

    Help!..

    Cheers

    Tuesday, December 17, 2013 4:34 PM
  • To answer my own question and confirm to others if needed/in doubt as I now have this working. You need to submit and buy a seperate digital certificate for each gateway and management server using the instructions above. For example I have a gateway and two management servers. I needed to create 3 different INF files (with the correct name) for each and I submitted these REQ's for 3 Entrust advantage certificates.

    For reference even though the gateway "connects" to one management server you need one for the other MS should the original be down and the gateway fails over.

    Friday, January 24, 2014 5:00 PM