Should I install my own CA for use with OWA?

  • Thread starter Thread starter mmac
  • Start date Start date
M

mmac

Using win2k, exchange 2k.
I need to enable Outlook Web Access for my traveling people, I understand
that to do this properly I need to use using SSL. I know next to nothing
about this subject so I am running through a technet article on the subject
and here are the first questions that come to mind, All this is assuming
that I should install my own CA. If I shouldn't why not?

1. I have a webserver, email server, and streaming media server, would it
matter which one I installed CA on?

2. Will anything on my existing LAN change when this is completed that I
would have to advise users about? Does this become a part of daily life or
only when the OWA is accessed?

3.Should I use an Enterprise CA or StandAlone? All legitimate users would
obviously have an email account and therefore be in AD so it seems that I
would want the Enterprise style. However, the OWA would be accessed from all
over the world on any number of outside networks. Does it matter where the
OWA would be accessed from?

4. how long should I make the Certs Valid for?

5. What good would a subordinate CA be for me? If I understand it correctly,
none?

I will have a bunch more but this is a start. Help?
 
My $0.02

1. Not sure.

2. Not much will change on the LAN. If you are using Microsoft Certificate
Services you should factor in backup/restore of the CA. Additionally, once
you make a machine a MS Certificate Services server, you can no longer
promote it to a DC (if it's a member server), nor demote it (if it's already
a DC)

3. I would suggest an AD-integrated CA. This means that machines in your
domain automatically trust the CA, and users using those machines (eg
laptops) will not get a warning about the certificate being issued by an
untrusted CA. That's a minor plus. The other alternatives are (a) buy an SSL
certificate from a trusted 3rd party vendor (eg Thawte, Verisign, Geotrust)
or (b) have the users put up wth the warning or (c) manually install the
CA's root cert into the user's certificate store

4. Up to you. A year, two years? Longer if you want.

5. I don't think it'll help you much given the facts at hand.

Cheers
Ken
 
1. Not sure.
Does that mean it doesn't matter which one I put it on?
2. Not much will change on the LAN. If you are using Microsoft Certificate
Services you should factor in backup/restore of the CA. Additionally, once
you make a machine a MS Certificate Services server, you can no longer
promote it to a DC (if it's a member server), nor demote it (if it's already
a DC)
Click to expand...

Thats because the certs would become invalid if I did, isn't that right?
3. I would suggest an AD-integrated CA. This means that machines in your
domain automatically trust the CA, and users using those machines (eg
laptops) will not get a warning about the certificate being issued by an
untrusted CA. That's a minor plus. The other alternatives are (a) buy an SSL
certificate from a trusted 3rd party vendor (eg Thawte, Verisign, Geotrust)
or (b) have the users put up wth the warning or (c) manually install the
CA's root cert into the user's certificate store
Click to expand...

Both types can be AD integrated, the enterprise version is manditory, the
standalone will use it if available. But use it how?
I have seen a script to install the cert in the trusted zones and I can
certainly install them into each users machine manually if I had to so that
doesn't bother me too much. But which one are you referring to when you say
AD integrated? It sound like enterprise?
 
Another 2 cents.

Unless you intend to make other uses of PKI beyond just
enabling SSL for OWA you may be best off just buying
a certificate from a public authority.

1. None of these. You root CA should be maintained in an
off-line state, with day-to-day being handled by a subordinate.
2. Not necessarily inform the users, but you would need to touch
all your client machines so that your CA is a trusted root.
3. If you do go the CA route, then enterprise. You do not indicate
whether your traveling people will only access OWA from
your mobile devices. If they will use unowned devices, then
those will not have your CA as trusted and so will not be able
to establish SSL. Use of a public cert is the most simple and
inexpensive way to enable any device to successfully use SSL
for your OWA.
4. probably a moot point by now
5. see above, in 1
 
Hmmm
Got me thinking about FreeSSL now...


Roger Abell said:
Another 2 cents.

Unless you intend to make other uses of PKI beyond just
enabling SSL for OWA you may be best off just buying
a certificate from a public authority.

1. None of these. You root CA should be maintained in an
off-line state, with day-to-day being handled by a subordinate.
2. Not necessarily inform the users, but you would need to touch
all your client machines so that your CA is a trusted root.
3. If you do go the CA route, then enterprise. You do not indicate
whether your traveling people will only access OWA from
your mobile devices. If they will use unowned devices, then
those will not have your CA as trusted and so will not be able
to establish SSL. Use of a public cert is the most simple and
inexpensive way to enable any device to successfully use SSL
for your OWA.
4. probably a moot point by now
5. see above, in 1
Click to expand...
 
mmac said:
Hmmm
Got me thinking about FreeSSL now...
Click to expand...

:-) or if it takes off the new Aussy effort

Building out your PKI is worth it if you have plans
to use it in enough ways. Getting your CA signed
for by a public root so it can issue for general public
use is timeconsuming and expensive.
 
well, expensive is not in my future so I guess I'll wander out to get
another type.
what is the Aussie effort you speak of?
 
Back
Top