locked
Certificate Problem RRS feed

  • Question

  • I have a setup with a production forest and a test forest.  I have a forest trust set up as well as DNS forwarding.  I have a client that is not on the AD and the system works correctly with Automatic Configuration.  However, any of the systems that are on the production AD fail with the following error:

    "There was a problem verifying the certificate from the server.  Please contact your system administrator."

    Is there a diag tool I can use to test my setup?
    Wednesday, April 4, 2007 8:29 PM

Answers

  • On the server that is your Certification Authority, go to Start-->Run and then type mmc.  Then go to File-->Add/Remove Snap-In.  Click the Add button and select Certificates from the list.  In the following dialog box, select computer account and click next.  Then select local computer and select finish.  Then click close and then OK.

    Expand Certificates (Local Computer) then expand Trusted Root Certification Authorities.  Then click on Certificates which will show all of the certs on the system on the right hand pane.  Locate the cert that you created for use with OCS and right click on it.  Select All Tasks --> Export.  This will bring the dialog box to save the file.  Save the exported cert in a locate that you can reach from the client side.  Once you have saved the file go to the client and perform the same steps to view the Certificates Snap-in on the client side.  Only this time, expand Certificates and then Trusted Root Certification Authorities but this time right click on Trusted Root Certification Authorities and select All Tasks --> Import.  Browse to the location where you saved the exported Cert and complete the import. 

    This procedure worked for me, but as I stated before, it does not solve the problem of the client not automatically applying the cert to its local store.  Therefore, this procedure is not very scalable for large scale deployments. 

    Hope that helps.  If you need me to clarify something or if it seems that I missed a step somewhere, let me know.

    Friday, April 6, 2007 3:00 PM

All replies

  • Update:

    I exported the cert from the system that was working and manually installed the cert on the machines that were having problems and now they can gain access.  So for some reason, the cert is not being installed on the client automatically.
    Wednesday, April 4, 2007 9:15 PM
  • Jason, Can you share what you did to fix the problem?

    I met similar issues and here is the error code: 0x80090325

    Log Name:      Application

    Source:        Communicator

    Date:          4/5/2007 7:03:59 PM

    Event ID:      1009

    Task Category: None

    Level:         Error

    Keywords:      Classic

    User:          N/A

    Computer:      SGLabPC1.SGADCLab.local

    Description:

    Communicator could not connect securely to server sglabwinsrv1.sgadclab.local because the certificate presented by the server was not trusted due to validation error 0x80090325.  The issuing certificate authority (CA) for the server's certificate may not be locally trusted by the client, the certificate may be revoked, or the certificate may have expired.

     

     Resolution:

     A tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit can be used in order to interpret the error code listed above.  If you trust the server certificate, the issuing certificate authority (CA) certificate can be placed in the local trusted root certificate authorities certificate store.  If you have logged into the server before without issues the network administrator should carefully examine the certificate if no known configuration changes have been made.

    Event Xml:

    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

      <System>

        <Provider Name="Communicator" />

        <EventID Qualifiers="49392">1009</EventID>

        <Level>2</Level>

        <Task>0</Task>

        <Keywords>0x80000000000000</Keywords>

        <TimeCreated SystemTime="2007-04-05T11:03:59.000Z" />

        <EventRecordID>1833</EventRecordID>

        <Channel>Application</Channel>

        <Computer>SGLabPC1.SGADCLab.local</Computer>

        <Security />

      </System>

      <EventData>

        <Data>Communicator</Data>

        <Data>sglabwinsrv1.sgadclab.local</Data>

        <Data>80090325</Data>

      </EventData>

    </Event>

     

    Thursday, April 5, 2007 11:12 AM
  • I didn't fix the problem.  I manually imported the cert onto the client machines for testing.  I am still unable to have the client automatically install the cert on the local machine.
    Thursday, April 5, 2007 5:59 PM
  • Could you tell me the steps on how to manually import the cert onto clien machines? Thanks.
    Thursday, April 5, 2007 11:12 PM
  • On the server that is your Certification Authority, go to Start-->Run and then type mmc.  Then go to File-->Add/Remove Snap-In.  Click the Add button and select Certificates from the list.  In the following dialog box, select computer account and click next.  Then select local computer and select finish.  Then click close and then OK.

    Expand Certificates (Local Computer) then expand Trusted Root Certification Authorities.  Then click on Certificates which will show all of the certs on the system on the right hand pane.  Locate the cert that you created for use with OCS and right click on it.  Select All Tasks --> Export.  This will bring the dialog box to save the file.  Save the exported cert in a locate that you can reach from the client side.  Once you have saved the file go to the client and perform the same steps to view the Certificates Snap-in on the client side.  Only this time, expand Certificates and then Trusted Root Certification Authorities but this time right click on Trusted Root Certification Authorities and select All Tasks --> Import.  Browse to the location where you saved the exported Cert and complete the import. 

    This procedure worked for me, but as I stated before, it does not solve the problem of the client not automatically applying the cert to its local store.  Therefore, this procedure is not very scalable for large scale deployments. 

    Hope that helps.  If you need me to clarify something or if it seems that I missed a step somewhere, let me know.

    Friday, April 6, 2007 3:00 PM
  • Okay, it seems that the issue was that because we are using an internal CA and not a public CA, the client side will  have to add the chain manually to the system.  This can be accomplished by going to the client that is going to use OC and using IE (uses ActiveX so you cannot use Firefox Sad ) to go to the web interface for your CA.  In my case the url was:

    http://<ip-address-of-CA>/certsrv

    Then enter the credentials a user on the AD to gain access.  At this point click on the link that says Download a CA Certificate, Certificate Chain or CRL.

    Then, near the top, click on install this CA certificate chain.  (If you get an ActiveX warning, allow the ActiveX to install).  

    For the following "Potential Scripting Violation" dialog box, select Yes.

    The next page should indicate success for the installation.

    If you are using a public CA, you should not have this issue, but for internal CA's, this is the procedure.
    Monday, April 9, 2007 8:14 PM
  • Great response Jason. Thanks for sharing your fix for others.
    Tuesday, April 10, 2007 5:50 AM
  • Jason,

     

    Thanks a lot for the steps. Today I managed to run Communicator on a Windows Vista client by following above procedures.

     

    But I don't fully understand your 2nd post - using http://<...>certsrv method. Is certsrv a specific example in your setup?

    Thursday, April 12, 2007 1:33 PM
  • Just wanted to offer my thanks, as well.  Jason's solution worked liked a charm!

     

    Cheers,

    Mark

    Tuesday, July 24, 2007 12:58 PM
  • I know I'm way behind on this thread, but I actually AM using a public cert (Equifax) and getting the exact same error and error code.  Any ideas?

    Thursday, July 26, 2007 12:15 AM
  • Same here....


    I have a GoDaddy cert I'm using for my dev environment.

     

    I have one OCS server with ISA publishing the 443 and 5061 ports to the system. I can see ISA forward the traffic on and can also get to the SSL web site https://<sitename>/conf/ext/tshoot.html.

     

    Any ideas??

     

    Thursday, October 4, 2007 7:26 AM
  •  

    Jason, did you get your cert from Go Daddy to work with OCS?  I have been working on this all day with little to no luck.  Just in the install phase, but the OCS will not accept the cert from Go Daddy.

     

    Thanks,
    Chris

    Thursday, October 18, 2007 8:47 PM
  •  

    I have gotten the actual Godaddy Certificate inastalled and configured on the OCS server. to get it installed, you have to import the mid cert that come with the certificate you got form godaddy. Just add it to the Trusted root Certificate group, and you will now see your godaddy cert when you try to add it to OCS...

     

     Now I am trying to get the server to start, and get this error...

    I have an AD domain with a diffe3rent name than the FQDN cert I bought. I have it applied fine,. but can;t figure out how to add it to the trusted server list.. I have added all three certs, the actual cert, the mid cert, and the root cert to all the sifferent areas of the certificates.msc fo rthe computer account... How can I fix this???

     

    Remote principal name is not configured in trusted server list.

    The subject name comm.itiliti.com of the certificate assigned to process DataMCUSvc(3596) was not found in the trusted server list.

    Certificate serial number: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US

    Certificate issuer name: 416D56.

    Resolution:

    Verify that the Subject Name of the certificate presented by the remote peer is configured in the trusted server list.

    For more information, see Help and Support Center at

    Friday, October 19, 2007 1:12 AM
  • Hi Chris,

     

    To get the GoDaddy certificates to work you can either go through the manual step of importing the root CA chain into your server's trusted certificate store...

     

    or

     

    What I did is just ran Windows Update and picked "other" from the list and chose "Root certificate update". This update package is included (i think) in Vista and will be in Windows 2008 Server.

     

    The issue I had with my previous post has now been resolved. As it turns out you MUST MUST MUST have something like the ISA server to translate remote Address Book and Web Component requests from the External URL to an Internal URL.

     

    I'm going to try and do up a Live Meeting recording on the configuration of this entire thing as its VERY confusing to say the least...

     

    Cheers,

     

    Jason

     

    Friday, October 19, 2007 6:21 AM
  •  

    Can you shed some light on your topology? Are you connecting internally or externally? Do you have an Edge server set up and if so, which certificate(s) do you have bound to which ports/ip's?

     

    Cheers!

     

    Jason

    Friday, October 19, 2007 6:23 AM
  •  

    I figured out the issue. I thought that the SSL cert from Godaddy would let mew specify a SAN for the external and internal FQDN, that is different fromt he FQDN of the OCS Pool. That is not the case.. SO I just used an internal cert, and now the server is loading up. But I can;t connect to it.. I am going ot spend a little more time on it trying ot get it working, but it is basically giving me this error: 

     

    Failed to establish security association with the server: User rneubauer Domain itiliti.com Protocol Kerberos Server sip/comm.itility.us Target Invalidated
    Suggested Resolution: Check whether the typed password and sign-in name are correct. Check whether the user is present in the AD and enabled for SIP. Check whether the target server is part of the Windows AD domain in which this user account is present. If this is a Kerberos failure check whether the client machine has access to the KDC. In some cases, Kerberos SA negotiation failures may be expected and hence can this error can be ignored.
    Failed to register user: User sip:rneubauer@itiliti.com @ Server comm.itility.us
    Failed to send SIP request: NegotiateSecurityAssociation failed, error: -2146893039
    Suggested Resolution: Make sure that the server is listening on the specified IP address/Port/Transport. If you have a firewall make sure that this port is open. Make sure that the server is running. If this is an Edge Server, ensure that remote user access has been enabled. This can be ignored if you have not enabled the transport on the target server

     

     

    Everything seems to be properly setup. Any ideas?

    Friday, October 19, 2007 6:31 AM
  • Okay, I followed Go Daddy's instructions for installing their cert on IIS and that worked.  I then reran the cert setup in the OCS installed and it let me select this cert as 'Assign an existing certificate'.  But something still doesn't seem right. 

     

    Can I do this in this order?

     

    Is any of these errors related to the cert issue?

     

    DNS Resolution succeeded: 192.168.180.18
    TLS connect failed: 192.168.180.18:5061 Error Code: 0x274d No connection could be made because the target machine actively refused it
    Suggested Resolution: Make sure that the server is listening on the specified IP address/Port/Transport. If you have a firewall make sure that this port is open. Make sure that the server is running. If this is an Edge Server, ensure that remote user access has been enabled. This can be ignored if you have not enabled the transport on the target server.
    Suggested Resolution: Ensure that the DNS records have been setup correctly. If this server is an Access Edge Server, make sure outside user access is enabled.

     

    Attempting to send a CCCP HTTP request https://jax-comm-svr1.corporate.local:444/LiveServer/Focus

     

    Received a failure HTTP response.: HTTP Response: 401
    Connection:close
    Content-Length:0
    Date:Fri, 19 Oct 2007 20:28:48 GMT
    Server:Microsoft-HTTPAPI/1.0

    Received a failure HTTP response.: Unauthorized
    Suggested Resolution: Check whether the Web Server or Office Communications Server component is running and also listening on the specified url. If server is behind a load balancer, please make sure the loopback connection is allowed from load balancer FQDN.
    Suggested Resolution: Check the Web Proxy setting in this machine and ensure that it is correctly configured

    Friday, October 19, 2007 8:37 PM
  •  

    What are you using for a firewall?

     

    Do you have an Edge server in your topology?

    Monday, October 22, 2007 4:41 AM
  •  ctcline wrote:

    Okay, I followed Go Daddy's instructions for installing their cert on IIS and that worked.  I then reran the cert setup in the OCS installed and it let me select this cert as 'Assign an existing certificate'.  But something still doesn't seem right. 

     

    Can I do this in this order?

     

    Is any of these errors related to the cert issue?

     

    DNS Resolution succeeded: 192.168.180.18
    TLS connect failed: 192.168.180.18:5061 Error Code: 0x274d No connection could be made because the target machine actively refused it
    Suggested Resolution: Make sure that the server is listening on the specified IP address/Port/Transport. If you have a firewall make sure that this port is open. Make sure that the server is running. If this is an Edge Server, ensure that remote user access has been enabled. This can be ignored if you have not enabled the transport on the target server.
    Suggested Resolution: Ensure that the DNS records have been setup correctly. If this server is an Access Edge Server, make sure outside user access is enabled.

     

    Attempting to send a CCCP HTTP request https://jax-comm-svr1.corporate.local:444/LiveServer/Focus

     

    Received a failure HTTP response.: HTTP Response: 401
    Connection:close
    Content-Length:0
    Date:Fri, 19 Oct 2007 20:28:48 GMT
    Server:Microsoft-HTTPAPI/1.0

    Received a failure HTTP response.: Unauthorized
    Suggested Resolution: Check whether the Web Server or Office Communications Server component is running and also listening on the specified url. If server is behind a load balancer, please make sure the loopback connection is allowed from load balancer FQDN.
    Suggested Resolution: Check the Web Proxy setting in this machine and ensure that it is correctly configured

     

    Are you trying to use the Communicator client or Live Meeting client? If so, are you using either of these on an internal or external network? Lastly, are you specifying the server name or trying to use Automatic sign in?

    Monday, October 22, 2007 4:45 AM
  • I too get the "Attempting to send a CCCP HTTP request " error.. when running the validation wizard:

     

     

    HTTP Connectivity Error : TrustFailure
    HTTP Connectivity Error : Trust failure can happen if the remote server presented a certificate
    that was not recognized as valid. This can also happen if the remote server certificate subject name
    is not recognized as a trusted server.

    HTTP Connectivity Error : Ensure that the certificate of the local server and remote server are both
    valid, have not expired, and contain valid subject name. In addition, ensure that the certificate chain
    of both Server(s) are valid. Ensure that the certificate chain of the local server is installed
    on the remote server and vice-versa. The most up-to date certificate chain that was used to issue
    the server certificate must be present.

    Failure
    [0xC3FC200D] One or more errors were detected

     

    Attempting to send a CCCP HTTP request https://serverb.domain.local:444/LiveServer/Focus

     

     

    Odd thing is.. i dont have this virtual directory called LiveServer.. In fact.. it was my other question as to how to install Live Server and where to get it from?

     

     

    Tuesday, October 23, 2007 6:00 PM
  • Hi jason,

    Thanks fo the tip, but it didnt work for me.
    I use an internal certificate with my external  domain as a Subject Alternate Name
    I directly add the certificate to the trusted root certification authorities folder to my remote clients but I still have this error :

    Communicator could not connect securely to server external.domain.com because the certificate presented by the server was not trusted due to validation error 0x80090325.  The issuing certificate authority (CA) for the server's certificate may not be locally trusted by the client, the certificate may be revoked, or the certificate may have expired.


    I really dont know if my configuration can work or not.
    Maybe i'm missing something.

    Can someone help me ?

    Thanks !
    Monday, November 5, 2007 12:36 AM
  • If you are going to use a certificate issued by in internal AD Enterprise CA then you'll need to copy not the certificate itself (which it appears you've done) but instead Root Certification Authority Certificate.

     

    Here's a technet article that should help: http://support.microsoft.com/kb/555252/en-us

     

    Once you have the root certificate imported in the local computer's Trusted Root Certification Authorities store then any certificates issued by that CA will be trusted by your computer.  If this client workstation is already a member of the domain in which the internal CA is located, then that cert should already be installed, so I'm assuming you are testing from a foreign, external workstation to test OC connectivity.

    Thursday, November 8, 2007 3:40 AM
    Moderator
  • Hi Jason,

     

    Is this correct or have I misunderstood something. You say "expand Trusted Root Certification Authorities" and "click on Certificates which will show al the certs on the system". When I do that I get all the certs belonging to the trusted root certification authorities which is what I would expect given that I have expanded something with that name. The certificate my colleague created for OCS doesn't appear in the list since it is not a trusted root certification authority. Have I missed something?

     

    Best wishes.....

    Colin

    Wednesday, November 21, 2007 9:59 PM
  • You can also solve this problem on another way:
    start -> run -> typ: services.msc -> check of "certificate authority" is availible.
    If it is not go to:
    start -> control panel -> add/remove programs -> add/remove windows components and select the certificate authority -> insert the windows server 2003 (if you use this version of server) and install the component.
    Tuesday, November 27, 2007 9:24 AM
  • Jason Hoss solution works perfect if you try to use UCMAPI in sharepoint.
    Tuesday, August 25, 2009 8:15 AM
  • Please check the list of Root Certificates installed on your client machines (typical Win XP -SP3 or Win Vista ). If the certificate you are installing on your server, is from a Cert Authority that isn't in your client list, you will have issues.

    As a recommendation, I would suggest pushing the root certificate to all machines using a GPO, and to machines that aren't on the domain, you can install KB931125 , which has a longer list (almost double) of certificates under the Microsoft Root Certificate Program, compared to what was shipped in Win XP/Vista.

    For Group Policies, please import your root certificate in the following path

    Computer Configuration >> Windows Settings >> Security Settings >> Public Key Policies  >> Trusted Root Certification  Authorities

    As a suggestion, I would have it on the default Domain Policy, so all machines to the domain get the certificate

    Monday, September 21, 2009 4:23 PM