ocs 2007 r2 edge certificates problem

MarkMichael
MarkMichael used Ask the Experts™
on
Hi experts,

I'm having trouble setting up my first edge server for ocs 2007 r2.
Current setup:

OCS Internal Server
- working fine
- set up with internal CA (specifically installed for this job)

OCS Edge (For IM only)
- got ports open between OCS Internal and Edge (443 and 5061)
- I have a single NIC with IPs
- - first IP is for example: 192.168.1.10
- - second IP is for example: 192.168.1.20 (we have NAT'd external address to this and set up the sip.domain.com and srv records to point to this NAT)

- I'm using the first IP as the Internal interface.
- I have set up the routing to next hop on the wizard and on the internal ocs server (added server fqdn to local hosts file).


The 2 certificates in use
1. Internal interface on the edge is from the Internal CA, generated an offline request, and processed it with the Internal CA and downloaded and installed by assigning it to Internal Interface through the wizard (had to install chain from Internal CA too, as they are not contactable)
2. External interface has a UCC certificate from comodo and I installed this fine too. Generated request with wizard and selected the box to include the server fqdn in the response (this being servername.domain.com and not sip.domain.com). Why do i need to include that?

I have only port 443 open to the NAT (external interface) and when connecting a client with auto configuration or manual, it says:
 

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

I currently dont have DNS outbound or web access on this server. Is this required? The certificate is showing up as valid from the certificate store.

Any ideas?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2018

Commented:
Open IIS, find your sites, and make sure that the SSL bound to your external-ish IP is your UCC cert and that the certificate in your SSL bindings on your internal IP is your internal cert. It is very likely that during the process, because you only have one NIC, the wizard was just a little too aggressive and assigned one certificate to both IPs on the NIC. Ideally you'd use 2 NIC's in such a configuration as the whole point of the edge server is to provide some level of isoluation between the external and internal network...which clearly is not happening with your current configuration.
You are most likely going to run into problems getting the Edge server to function correctly with only a single network interface and both internal and external IPs on the same subnet.

Take a look at each of these blog article for detailed OCS Edge Server requirements and best practice guidlines (pay special attention to the first article):
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=15
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=19
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=33
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=78

Also, the Edge Server FQDN should NOT be included in the External Edge certifications.  The same wizard is used for internal and external request, so you are not supposed to check the 'include Servername in request' checkbox when creating a certificate for an Edge External role.  Only the internal Edge cert should include the server FQDN.

Take a look at this article for additional details on Edge certificate configuration scenarios:
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=79

Author

Commented:
Thank you guys, I will give that a go tomorrow morning. I'll let you know my findings. I think i'm going to have to add another interface.

This server is segregated away from the internal LAN by being in a separate VLAN as it stands. I'm have a chat with networks and see if they can give me another range to apply this NAT to.

This document looks just what I need too. Thanks!
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

Author

Commented:
Hi Jeff,

Excellent article and it's given me great insight for this deployment.

However, I am faced with a different issue, since I have added more interfaces. My deployment looks like so: hope you can help!

Internal network (VLAN 001)

192.168.1.0/24

OCS Internal : 192.168.1.10


Perimeter network (VLAN 999)

172.16.0.0/24

OCS Edge :

Internal Interface:        172.16.0.10 (default gateway 172.16.0.10)
Access Edge Interface: 172.16.0.20 (NAT'd External IP to this IP address)
Webconf Interface:       172.16.0.30
AV Interface:                 172.16.0.40


I've checked the ability to connect to the port listening on 172.16.0.20 via the External address from a client outside the network and telnet shows this is listening. So the NAT'ing is working.

-----

There is connectivity through OCS Internal and OCS Edge on ports 443 and 5061, I've used telnet to check.

On the Edge server, I have only enabled 443 in/out on the Edge server.
Does the server need 5061 by any chance, just for IM?
Also, does it need to be able to DNS anything, perhaps for any sort of certificate verification or not?

MUST I use separate subnets?

I have tried the interfaces changes like suggested in your blog but they do not seem to help.

eg.
netsh interface ipv4 set interface 14 weakhostsend=enabled
netsh interface ipv4 set interface 14 weakhostreceive=enabled
(replaced with correct interface value)

I've also applied the default gateway to both NICs, but no help.
-----


The error I'm now receiving is 'cannot sign in because the server is temporarily unavailable).

Can you please help on what network rules I need, as I don't see these as clear currently and is there anything else you can suggest please?
Distinguished Expert 2018

Commented:
Why is our OCS internal interface still on the external subnet? How is the OCS edge server supposed to find and communicate with the OCS internal server? (or vice versa?) You have a broken topology, still.

Author

Commented:
Because it has a hosts file, pointing to its IP address.

The ports are open and the firewall we use, is directly connected to both these VLANs.

I have checked that this connectivity is fine, I can telnet to the internal servername from the Edge server on the required ports.

I have also checked this from the reverse direction.

Next please?
Distinguished Expert 2018

Commented:
hosts files don't cut it. SIP is *very* sensitive to routing issues. You need to configure a proper topology; no shortcuts.
 

Author

Commented:
For an Edge server, I have never set up DNS, I have always used HOSTS.

I cannot allow DNS to used from the Internal VLAN for this server.

What other way can I use this?
The internal interface needs to be (1) on a separate IP network than the external interfaces, and (2)
able to directly route traffic between the Edge Internal interface and the Front-End server.  If you are performing NAT between those then the Edge Server will not work correctly.

The HOSTS file entry only provide name resolution, to does not override an routing requirements. And telnetting to the service may validate that it's listening, but OCS still can't operate in that configuration correctly.  It's an internal routing issue with how the Edge Server functions.  Yes, you must use different subnets.

I also suggest using only two interfaces and not four.  You can scale out to more later if you need the bandwidth, but all 3 external roles on a single external interface is easier to deploy.

By default TCP443 is used for external client connections and TCP5061 is used for server-to-server Federation and PIC.

You should be pointing to internal DNS servers for the Edge Server's primary/secondary DNS server settings. It requires DNS resolution just like and Windows Server.  Also, since you are using NAT you'll need to create an internal DNS record for your A/V external FQDN (e.g. av.domain.com) which resolves to the PUBLIC IP address and not the internal private IP on the server.   This is only the A/V IP that requires this as it's linked to enabling the 'Use NAT for A/V' setting on the Edge interfaces properties.

Distinguished Expert 2018
Commented:
You can continue to use hosts (although I recommend strongly against it), but the bigger probelm is that your internal NIC is on the same subnet as your external NIC which is gonna play all sorts of strings with the OCS engine. You need to trim down your topology.
 
External NIC(subnet 1)-->OCS Edge-->Internal NIC(subnet 2)-->switch/hub-->OCS-FrontEnd(Subnet 2)
or....if you want a firewall between the internal NIC and the edge:
External NIC(subnet 1)-->OCS Edge-->Internal NIC(subnet 2)-->firewall WITH PROPER NAT-->OCS-FrontEnd(Subnet 3)
Any which way, your external NIC shold not be seeing trraffic from your internal NIC and vice versa.
Jeff actually already gave you a link with several supported topologies which I'll repeat here but I give him full credit, both for the link and the original blog post that he quite thoroughly wrote out:
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=19
The very first diagram basically shows the topology you can go after even in a minimal configuration and use hosts files to avoid using DNS. Notice that firewall? Big red line between the edge and the front-end server? Also notice how the internal NIC and external NIC are on two different subnets on the variation that is diagram 2? (10.1. vs 10.2.)
This isn't optional. Reread his blog post. Reread the deployment guidees. Proceed methodically and carefully. Once you do, you'll see your issue vanish.

Author

Commented:
Ok,

I've read over this several times. What am I missing here?

Reconfigured the network.

Corporate LAN has:

OCS Front-End
192.168.1.10 (single interface)


OCS Edge
Internal Interface:
192.168.1.20 (

External Interfaces
Access Edge Interface: 172.16.0.20 (NAT'd External IP to this IP address)
Webconf Interface:       172.16.0.30
AV Interface:                 172.16.0.40


This is giving me the ability to use DNS from the corporate network to point to the servers.
Also giving me 2 subnets that are routable, one to another.

Ports appear open between the edge/front-end.

Certificate is installed from public CA and internal CA.

Would there be a problem as the OCS Front-End server acting as the certificate authority too?

Author

Commented:
No more suggestions?
Distinguished Expert 2018

Commented:
Since you've made these configuration changes, what symptoms are you now seeing?

Author

Commented:
Office Communicator client, comes up with:

Cannot sign in because the server is temporarily unavailable. If the problem persists, contact your system administrator.


Event log (Application) says:
Communicator could not connect securely to server sip.domain.com because the certificate presented by the server was not trusted due to validation error 0x80090326.  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.

Event log (System) says:
The following fatal alert was received: 40.



The certificate is from Comodo and only contains sip.domain.com as the common name. This is a UCC certificate too.
I also re-read your initial post, I cannot find any IIS websites on the edge server. I have tried installing the IIS administrative tools and there are no websites on this server.

Is there somehow, a way to view which certificate I'm being presented with, telnet to that ip on 443 obviously wont show anything...

Does it matter that this servers hostname is not the same name as sip.domain.com?
Distinguished Expert 2018

Commented:
No, this is a CA issue, as the error very clearly states.
Let's try re-assigning the comodo certificate:
1. Edge Server->Deployment Wizard->Deploy Edge Server page->Configure Certificates for the Edge Server->Run button
2. Welcome page->Next
3. Available Certificate Tasks page->Assign an existing certificate->Next
4. Available Certificates page->select the Comodo certificate->Next
5. Available Certificate Assignments page->Edge Server public interface check box->Next
6. Review and finish

Author

Commented:
Hi,

Sorry for the late reply.

I've completed the assignment again, but this has not resolve it.
Checking the event log and communicator again, it is reporting the same error.

Author

Commented:
Would Microsoft be able to help with this do you think?

Also, would it cost?

Ta
Distinguished Expert 2018

Commented:
I'm sure Microsoft could help, and yes I'm sure it'd cost.
If paying is something you are going to do, I'd recommend getting someone in who can insepct your topology though, as we've already established it had issues. If you are still getting your internal certificate, I'm more likely to suspect your netowrk layout than I am your OCS setup.

Author

Commented:
Sounds good. I will give them a ring Monday. I cant see another way of setting this up from our perspective. Would you suggest something different perhaps?
Distinguished Expert 2018

Commented:
Nope. EE's policy (rightfully so) is that help stays within the thread, so experts aren't doing real "remote support" sessions or promoting paid services to do so. And sometimes a problem really does need that "hands on" touch, so getting the answers you need via EE simply isn't possible and an outside source must be used.
Good luck, and I hope you can follow what MS does and can post back what they found. I'd be interested in knowing.
-Cliff
 

Author

Commented:
Cliff,

I'd be happy to.
Hopefully we'll have a working product in a few days.

Many thanks for your help so far.

Author

Commented:
Finally. Works. :D

Looks like during the config of the original server, when i used a diff server name and fqdn, some of these settings seem to only be changable by re-running the installer from the CD.

MS checked the settings and changed the 'next hop' server to the correct name. This didnt seem to resolve it. After a few other little things like that, jumping between both the internal and edge OCS server. Still, we came up with the same error. Unable to connect to server etc.

They left me and advised to go and get the latest updated. Pointed me at a website and told me to download a serverupdate.exe and it checked my versions and updated automatically. I did this on both edge and internal.

This now started giving me different/additional (more detailed) errors in the OCS event log. Once i resolved the errors, I had certificate errors on my internal nic on the edge server. To which I re-created on my Internal CA.

During this period, I got my Public CA to reissue a replacement certificate and this time to give it to us in the form of a .cer instead of a .crt.

Put these on and the services started without a problem.

Tested the client connection and it worked by prompting me for a user/pass. Great stuff.

Continued and it connected.


In Brief it was resolved by:

If you have changed your server name, redeploy from the CD, entering the new names as appropriate.
Install latest updates from MS.
Regenerated my Internal CA and public CA where necessary.

Connection Granted :)


Thanks for all your help.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial