Remove From My Forums

OCS Edge Server validation error. Possibly certificates related.

Question
0

Sign in to vote

I've looked at many posts with similar errors and have been unable to resolve the errors I receive during Edge Server Validation. It appears to me to be certificate related, but there could be other issues behind this. I'm far from knowledgeable in this area. I'm having trouble with getting federated users to see each other. Let me know if more information is needed, and thanks in advance for any help.


All servers running Windows Server 2008 Enterprise, 64-bit. Using OCS 2007 R2 Enterprise Edition.

Two domains (Fabrikam.com, and contoso.com). Each with 4 servers:

DC (with DNS and CA)

Communicator Web Access

Office Communicator Server

Access Edge Server (with Forefront TMG)

A separate CA machine outside of both domains.

When running the Edge Server validation (occurs when run on either domain, for simplicity all errors in this post are from running the validation on fabrikam edge server FAB-AES.fabrikam.com), I get an error during Direct Partner CON-AES.contoso.com:

                DNS Resolution succeeded: 10.0.0.15

                TLS handshake failed: 10.0.0.15:5061 Error Code: 0x0 Connection Timeout.

Under Check two-party IM:

Sip dialogs pass for connecting between users on the same domain.

Attempting to establish SIP dialog from kralls@fabrikam.com to sip:michaelbly@contoso.com using pool01.Fabrikam.com

                Maximum hops: 2

                Check two party IM: Discovered a new SIP server in the path.

                Maximum hops: 3

Received a failure SIP response: User sip:michaelbly@contoso.com @ Server pool01.Fabrikam.com
Received a failure SIP response: [
SIP/2.0 504 Server time-out
FROM: "Kim Ralls"<sip:kralls@fabrikam.com>;tag=ca945f371d1aebf1da18;epid=epid01
TO: <sip:michaelbly@contoso.com>;tag=EB2DBB1ECE3749884032242BA0153D71
CSEQ: 10 INVITE
CALL-ID: 8b01f79f29ca4a9a9d0b47f2c3e39d4c
VIA: SIP/2.0/TLS 10.0.1.15:10294;branch=z9hG4bK4ec554f9;ms-received-port=10294;ms-received-cid=1800
CONTENT-LENGTH: 0
AUTHENTICATION-INFO: NTLM rspauth="010000000000000038BDF6856EFAD4AB", srand="9271DE00", snum="13", opaque="A45AF10D", qop="auth", targetname="FAB-OCS.Fabrikam.com", realm="SIP Communications Service"
ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;ms-ep-fqdn=FAB-AES.fabrikam.com;ms-source-verified-user=verified;ms-source-network=federation
ms-diagnostics: 1010;reason="Certificate trust with next-hop server could not be established";source="FAB-AES.Fabrikam.com";ErrorType="The peer certificate is not chained off a trusted root";HRESULT="0x80090325"

]

Suggested Resolution: Use the maximum hop count to determine the server that generated this error. For example, if the maximum hop value is 2, then it is likely that this error was generated by a server that is 1 (immediate target) or 2 hops away. Check whether the target user is a valid user and that the target user domain is trusted by the source user's pool. Check the connectivity between the source and target pools.
Suggested Resolution: Check connectivity between servers. If this is an Edge Server, ensure that it is present in the forest-level Edge Server table.

The Edge Server Event Log shows this error:

TLS outgoing connection failures.

Over the past 30 minutes Office Communications Server has experienced TLS outgoing connection failures 19 time(s). The error code of the last failure is 0x80090325 (The certificate chain was issued by an authority that is not trusted.) while trying to connect to the host "CON-AES.contoso.com".
Cause: Wrong principal error could happen if the peer presents a certificate whose subject name does not match the peer name. Certificate root not trusted error could happen if the peer certificate was issued by remote CA that is not trusted by the local machine.
Resolution:
For untrusted root errors, ensure that the remote CA certificate chain is installed locally. If you have already installed the remote CA certificate chain, then try rebooting the computer.

External Interface Settings

Role:    IP Address:     DNS Name:    Port:    Certificate:

Access 192.168.0.11 FAB-AES.Fabrikam.com 5061 (Federation) Certificate Authority rootCA

443 (Remote) Subject FAB-AES.Fabrikam.com

Subject Alternate Name sip.fabrikam.com

pool01.Fabrikam.com

FAB-AES.Fabrikam.com

Creation Date 7/17/2009

Expiration Date 7/17/2010

Web Conferencing 192.168.0.11 FAB-AES.fabrikam.com 442 Certificate Authority rootCA

                                                                                                Subject FAB-AES.fabrikam.com

Subject Alternate Name <None>

Creation Date 6/17/2009

Expiration Date 6/17/2010

A/V 192.168.0.11 FAB-AES.fabrikam.com 441 >None required> 50000 - 59999

When looking at the certificates with the certificate snap-in within mmc, the certificate path shows RootCA and states certificate is ok. The external certificates were issues from the standalone CA (outside of each domain) which I downloaded and installed the certificate chain from on both Edge Servers.

I’ve tried numerous certificate subject names and have been unable to get this working (sip.fabrikam.com, or pool01.fabrikam.com; the results may have been slightly different, I don't recall at this point). This is far from my area of expertise and I am now spinning my wheels.

Friday, July 17, 2009 10:21 PM

All replies

0

Sign in to vote

I'm not sure which FQDN is what, but ideally you should have the following configured on the Edge server:
Internal Interface
- Issued by internal Windows Enterprise CA
- Subject Name is the server's FQDN (e.g. ocsedge.internal.contoso.com)
Access Edge Server
- Issued by trusted third-party certificate authority
- Subject Name is the FQDN used by the client to connect (e.g. sip.contoso.com)
Web Conferencing Edge Server
- Issued by trusted third-party certificate authority
- Subject Name is unique FQDN (e.g. webconf.contoso.com)
A/V Authentication Edge Server

Issued by either internal Windows Enterprise CA (recommended) or trusted third-party certificate authority
Subject Name is unique FQDN (e.g. av.contoso.com)

FQDN's for any additional SIP domains should be added to the SAN fields. You should not have yout internal FQDN on any of the external cert's SAN fields.

You also may be running into issues by running all three Edge roles on the same IP address and changing default ports. It does work, but can be difficult to do so.

Saturday, July 18, 2009 1:53 PM

Moderator

Jeff-

Thank you for the response.

However, after the changes, I am still getting the same error. I changed the WebConference and A/V ips (added Host A records to DNS) and issues new certs for these. Changed Internal Interface cert to sip.domain .com on each domain. Here are the changes I have made,and the validation and event log results; again, these are from Fabrikam domain, changes also made to contoso domain:

Edge Server Status

External User Access

Remote user access: (check )
	Anonymous user access: (X )
Federated contacts: (X ) I’m unsure about why this is an X, or if it is an issue. Users all have “enable federation” selected. On Edge Server “Federate with other domains”, “Allow Discovery of federated partners”, and “Enable archiving disclaimer notification to federated users” are enabled. Under User Access Settings “Allow remote user access to your network” is enabled. The “Allow users to communicate with federated contacts” is greyed out.

Federation and Public IM

Allow Federation: (check )

Allow discovery of federation partners: (check )

Archiving Disclaimer: (check )

A llowed federation partner domains

Access Proxy: Domain:

con-aes.contoso.com contoso.com

Ex ternal Interface Settings

Role:

IP Address:

DNS Name:

Port:

Certificate:

Access

192.168.0.11

sip.fabrikam.com

5061 (Federation)

Certificate Authority

rootCA (external CA)

443 (Remote)

Subject

sip.fabrikam.com

Subject Alternate Name

<None>

Creation Date

7/18/2009

Expiration Date

7/18/2010

Web Conferencing

192.168.0.12

web.fabrikam.com

443

Certificate Authority

rootCA (external CA)

Subject

web.fabrikam.com

Subject Alternate Name

<None>

Creation Date

7/18/2009

Expiration Date

7/18/2010

A/V

192.168.0.13

FAB-AES.fabrikam.com

443

50000 - 59999

Internal Interface Settings

IP Address:

10.0.1.15

DNS Name:

FAB-AES.fabrikam.com

Next Hop Address:

pool01.fabrikam.com

Next Hop Port:

5061

TLS Certificate Information:

Certificate Authority:

rootCA (internal CA)

Subject:

FAB-AES.fabrikam.com

Subject Alternate Name:

<None>

Creation Date:

6/17/2009

Expiration Date:

6/17/2010

User Authentication Certificate Information:

Certificate Authority:

rootCA (internal CA)

Subject:

av.fabrikam.com

Subject Alternate Name:

FAB-AES.Fabrikam.com
av.fabrikam.com

Creation Date:

7/18/2009

Expiration Date:

7/18/2010

Internal Edge Ports

	Role:	Port:
	Access	5061
	Web Conferencing	8057
	A/V TCP	443
	A/V User Authentication	5062

Authorized Internal Servers

	pool01.fabrikam.com
	FAB-OCS.fabrikam.com
Supported Internal Domains
		fabrikam.com

Validation

Direct Partner CON-AES.contoso.com

DNS Resolution succeeded: 10.0.0.15
TLS handshake failed: 10.0.0.15:5061 Error Code: 0x0 Connection Timeout.
Failure
[0xC3FC200D] One or more errors were detected

Check two-party IM

Attempting to establish SIP dialog from kralls@fabrikam.com to sip:michaelbly@contoso.com using pool01.Fabrikam.com Maximum hops: 2
Check two-party IM: Discovered a new SIP server in the path.
Maximum hops: 3
Received a failure SIP response: User sip:michaelbly@contoso.com @ Server pool01.Fabrikam.com
Received a failure SIP response: [
SIP/2.0 504 Server time-out
FROM: "Kim Ralls"<sip:kralls@fabrikam.com>;tag=ef91faa1cd86f261f55;epid=epid01
TO: <sip:michaelbly@contoso.com>;tag=6079B6163A892D9C92398F0589DB0F41
CSEQ: 10 INVITE
CALL-ID: 89ff1e5b413f454395b6ca51741685c0
VIA: SIP/2.0/TLS 10.0.1.15:10162;branch=z9hG4bK347a6c3d;ms-received-port=10162;ms-received-cid=FB00
CONTENT-LENGTH: 0
AUTHENTICATION-INFO: NTLM rspauth="0100000000000000595BA75CCEC3EA2D", srand="C6FA9812", snum="13", opaque="F082604F", qop="auth", targetname="FAB-OCS.Fabrikam.com", realm="SIP Communications Service"
ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;ms-ep-fqdn=FAB-AES.fabrikam.com;ms-source-verified-user=verified;ms-source-network=federation
ms-diagnostics: 1010;reason="Certificate trust with next-hop server could not be established";source="sip.fabrikam.com";ErrorType="The peer certificate is not chained off a trusted root";HRESULT="0x80090325"

]

Suggested Resolution: Use the maximum hop count to determine the server that generated this error. For example, if the maximum hop value is 2, then it is likely that this error was generated by a server that is 1 (immediate target) or 2 hops away. Check whether the target user is a valid user and that the target user domain is trusted by the source user's pool. Check the connectivity between the source and target pools.
Suggested Resolution: Check connectivity between servers. If this is an Edge Server, ensure that it is present in the forest-level Edge Server table.
Failure
[0xC3FC200D] One or more errors were detected

Event Log

7/20/2009 10:13:44 AM OCS Protocol Stack 1001 14428 (error)

TLS outgoing connection failures.

Over the past 1 minutes Office Communications Server has experienced TLS outgoing connection failures 1 time(s). The error code of the last failure is 0x80090325 (The certificate chain was issued by an authority that is not trusted.) while trying to connect to the host "CON-AES.contoso.com".
Cause: Wrong principal error could happen if the peer presents a certificate whose subject name does not match the peer name. Certificate root not trusted error could happen if the peer certificate was issued by remote CA that is not trusted by the local machine.
Resolution:
For untrusted root errors, ensure that the remote CA certificate chain is installed locally. If you have already installed the remote CA certificate chain, then try rebooting the computer.

7/20/2009 10:13:43 AM OCS Protocol Stack 1001 14380 (warning)

Some requests were rejected as they exhausted the Max-Forwards limit.

In the past 1 minutes, the protocol stack rejected 1 requests that were looping and exhausted the Max-Forwards limit. The last such request had the From uri (sip:kralls@fabrikam.com) and the To uri (sip:michaelbly@contoso.com).
Cause: This usually indicates an incorrect server configuration or a bad routing rule.
Resolution:
None needed unless the number of reported errors is large (> 100). This usually indicates an incorrect server configuration or a bad routing rule. Check whether all server routing rules are properly configured.

-Jon

Monday, July 20, 2009 6:03 PM

Asked by:

OCS Edge Server validation error. Possibly certificates related.

Question

All replies