| Groups | Blog | Home |
dotnet security : IIS "secure communications"and "certificate" sections disabled.
Hi, there:
This might be a newbie question. I want my web service to require a certificate to access, so I go to IIS my virtual directory property and Directory Security page. I found the "secure communication" secion including "Server certificate" button are both greyed out. I wonder why that is. I'm an admin user of the computer. Did I miss some OS component or something?
I read the articles in msdn, about generating and installing a server
certificate, it says I need to click "server certificate" button to get to Server Certificate generation wizard. Maybe I misunderstand it? Now the problem is: how to generate a server certificate? Or... what is a better way to restrict who can access my web service? I'm writing the service in .net and someone is gonna access it from unix platform with java. [quoted text, click to view] "Nicole Calinoiu" wrote:
> The "server certificate" button is never available below the site level. > The other buttons will only become available at the virtual directory level > once you assign a certificate to the site. > > HTH, > Nicole > > > "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message > news:EF05BFAD-DB53-4720-96B5-864B010D99FE@microsoft.com... > > Hi, there: > > This might be a newbie question. I want my web service to require a > > certificate to access, so I go to IIS my virtual directory property and > > Directory Security page. I found the "secure communication" secion > > including > > "Server certificate" button are both greyed out. I wonder why that is. I'm > > an > > admin user of the computer. Did I miss some OS component or something? > > > > > >
Thanks! I got it. ( thought the link for list of authorities to issue
certificate doesn't really work for the last step. ) Anyway, about the web service authentication, here're the 3 ways I can think of: 1. Use IIS IP restriction. Only allows certain IP to access service. 2. Use Certificate. This involves a fee to get the certificate for server and client. 3. Use WSE2.0, web service enhancement toolkit. This can only be used when server and client are both using .net framework 1.1, both have to install the toolkit. Am I understanding it right? What're the pros and cons of the approaches? And... are there any other ways? I am now writing my service in .net, and my intended client is using java on unix. Thanks a lot! [quoted text, click to view] "GoCMS" wrote:
> Hi, there: > This might be a newbie question. I want my web service to require a > certificate to access, so I go to IIS my virtual directory property and > Directory Security page. I found the "secure communication" secion including > "Server certificate" button are both greyed out. I wonder why that is. I'm an > admin user of the computer. Did I miss some OS component or something? >
The "server certificate" button is never available below the site level.
The other buttons will only become available at the virtual directory level once you assign a certificate to the site. HTH, Nicole [quoted text, click to view] "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message news:EF05BFAD-DB53-4720-96B5-864B010D99FE@microsoft.com... > Hi, there: > This might be a newbie question. I want my web service to require a > certificate to access, so I go to IIS my virtual directory property and > Directory Security page. I found the "secure communication" secion > including > "Server certificate" button are both greyed out. I wonder why that is. I'm > an > admin user of the computer. Did I miss some OS component or something? > >
The "server certificate" button should be available in your _web site_
properties, not the individual virtual directory properties. Unless you've been altering the site(s) hosted on your machine, it'll probably be named "Default Web Site". HTH, Nicole [quoted text, click to view] "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message news:3D79778C-8039-40E3-B40E-A68868DA69C6@microsoft.com... >I read the articles in msdn, about generating and installing a server > certificate, it says I need to click "server certificate" button to get to > Server Certificate generation wizard. Maybe I misunderstand it? > Now the problem is: how to generate a server certificate? > > Or... what is a better way to restrict who can access my web service? I'm > writing the service in .net and someone is gonna access it from unix > platform > with java. > > "Nicole Calinoiu" wrote: > >> The "server certificate" button is never available below the site level. >> The other buttons will only become available at the virtual directory >> level >> once you assign a certificate to the site. >> >> HTH, >> Nicole >> >> >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message >> news:EF05BFAD-DB53-4720-96B5-864B010D99FE@microsoft.com... >> > Hi, there: >> > This might be a newbie question. I want my web service to require a >> > certificate to access, so I go to IIS my virtual directory property and >> > Directory Security page. I found the "secure communication" secion >> > including >> > "Server certificate" button are both greyed out. I wonder why that is. >> > I'm >> > an >> > admin user of the computer. Did I miss some OS component or something? >> > >> > >> >> >>
[quoted text, click to view]
"GoCMS" <GoCMS@discussions.microsoft.com> wrote in message news:9DDDB619-71FB-4793-A582-8EF48217255B@microsoft.com... > Thanks! I got it. ( thought the link for list of authorities to issue > certificate doesn't really work for the last step. ) > > Anyway, about the web service authentication, here're the 3 ways I can > think > of: > 1. Use IIS IP restriction. Only allows certain IP to access service. There are a few problems with this one: a. The message won't be encrypted, so any sensitive data will potentially be exposed to eavesdroppers. b. IP addresses can be spoofed. c. Clients with dynamic IP addresses won't be able to connect (unless you remap to their new addresses, which adds a potential attack point). [quoted text, click to view] > 2. Use Certificate. This involves a fee to get the certificate for server > and client. Not necessarily. For the server, a commercial certificate would probably be a good idea, but you could use a self-issued certificate if you're dead set against paying for one. Of course, convincing your client to trust your self-issued certificate would be a whole other story... It isn't necessary to use client certificates for authentication just because you're using a server certificate for other purposes (e.g.: SSL). If you do want to use client certificates for authentication, you could issue them yourself. After all, you're the only one who needs to trust them. As a bit of a side note, regardless of what other mechanisms you may select for encryption and/or authentication, applying a server certificate and enforcing the use of HTTPS when calling your web service over the internet would be good way to enhance the security of the system reasonably cheaply (both in terms of time and money). [quoted text, click to view] > 3. Use WSE2.0, web service enhancement toolkit. This can only be used when > server and client are both using .net framework 1.1, both have to install > the > toolkit. Not true. WSE renders web service messages that are supposed to be compliant with the WS-* standards. Depending on the tools available to your clients, they may find supporting these standards to be somewhat more or less difficult than it is via WSE. You should probably discuss this with them. [quoted text, click to view] > Am I understanding it right? What're the pros and cons of the approaches? > And... are there any other ways? Yes. There are quite a few possible combinations of authentication and encryption schemes. Your best bet may be to take a look at http://msdn.microsoft.com/webservices/building/interop/ in order to target your research at the scenario you need to support. [quoted text, click to view] > I am now writing my service in .net, and my intended client is using java > on > unix. > > Thanks a lot! > > > "GoCMS" wrote: > >> Hi, there: >> This might be a newbie question. I want my web service to require a >> certificate to access, so I go to IIS my virtual directory property and >> Directory Security page. I found the "secure communication" secion >> including >> "Server certificate" button are both greyed out. I wonder why that is. >> I'm an >> admin user of the computer. Did I miss some OS component or something? >> >>
Hi, Nicole:
Thanks a lot of your reply. My web service is going to be used only in intranet, so this is a lot easier to handle. It's just the caller will be java on unix. About the WSE 2.0 approach, it requires my caller to install a java plugin, and that makes it harder. I am thinking of the certificate method. How to generate and install a free client certificate. Thanks! [quoted text, click to view] "Nicole Calinoiu" wrote:
> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message > news:9DDDB619-71FB-4793-A582-8EF48217255B@microsoft.com... > > Thanks! I got it. ( thought the link for list of authorities to issue > > certificate doesn't really work for the last step. ) > > > > Anyway, about the web service authentication, here're the 3 ways I can > > think > > of: > > 1. Use IIS IP restriction. Only allows certain IP to access service. > > There are a few problems with this one: > > a. The message won't be encrypted, so any sensitive data will potentially > be exposed to eavesdroppers. > b. IP addresses can be spoofed. > c. Clients with dynamic IP addresses won't be able to connect (unless you > remap to their new addresses, which adds a potential attack point). > > > > 2. Use Certificate. This involves a fee to get the certificate for server > > and client. > > Not necessarily. For the server, a commercial certificate would probably be > a good idea, but you could use a self-issued certificate if you're dead set > against paying for one. Of course, convincing your client to trust your > self-issued certificate would be a whole other story... > > It isn't necessary to use client certificates for authentication just > because you're using a server certificate for other purposes (e.g.: SSL). > If you do want to use client certificates for authentication, you could > issue them yourself. After all, you're the only one who needs to trust > them. > > As a bit of a side note, regardless of what other mechanisms you may select > for encryption and/or authentication, applying a server certificate and > enforcing the use of HTTPS when calling your web service over the internet > would be good way to enhance the security of the system reasonably cheaply > (both in terms of time and money). > > > > 3. Use WSE2.0, web service enhancement toolkit. This can only be used when > > server and client are both using .net framework 1.1, both have to install > > the > > toolkit. > > Not true. WSE renders web service messages that are supposed to be > compliant with the WS-* standards. Depending on the tools available to your > clients, they may find supporting these standards to be somewhat more or > less difficult than it is via WSE. You should probably discuss this with > them. > > > > Am I understanding it right? What're the pros and cons of the approaches? > > And... are there any other ways? > > Yes. There are quite a few possible combinations of authentication and > encryption schemes. Your best bet may be to take a look at > http://msdn.microsoft.com/webservices/building/interop/ in order to target > your research at the scenario you need to support. > > > > > I am now writing my service in .net, and my intended client is using java > > on > > unix. > > > > Thanks a lot! > > > > > > "GoCMS" wrote: > > > >> Hi, there: > >> This might be a newbie question. I want my web service to require a > >> certificate to access, so I go to IIS my virtual directory property and > >> Directory Security page. I found the "secure communication" secion > >> including > >> "Server certificate" button are both greyed out. I wonder why that is. > >> I'm an > >> admin user of the computer. Did I miss some OS component or something? > >> > >> > >
For an intranet-only application, use of an internally generated server
certificate would probably be OK as well. For generating the client and/or server certificates, the first step would be to determine whether there is already a CA (certification authority) running on the network. The best way to do this would be to ask the network infrastructure folks in IT. If there is no CA in place already, then it would be necessary to set one up if certificates are to be generated internally. Since the same network infrastructure folks would presumably be responsible for its setup and maintenance, this should be planned with them. If they have no other use for an internal CA, it might be cheaper and easier to buy the certificates. However, if they do want to set up a CA and are already running Windows servers, the Microsoft CA would be a reasonable choice. For documentation on the Microsoft CA, see http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_cs_topnode.asp. [quoted text, click to view] "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message news:08480628-9790-4BDE-88B4-1EF075D57631@microsoft.com... > Hi, Nicole: > Thanks a lot of your reply. My web service is going to be used only in > intranet, so this is a lot easier to handle. It's just the caller will be > java on unix. About the WSE 2.0 approach, it requires my caller to install > a > java plugin, and that makes it harder. I am thinking of the certificate > method. How to generate and install a free client certificate. > Thanks! > > "Nicole Calinoiu" wrote: > >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message >> news:9DDDB619-71FB-4793-A582-8EF48217255B@microsoft.com... >> > Thanks! I got it. ( thought the link for list of authorities to issue >> > certificate doesn't really work for the last step. ) >> > >> > Anyway, about the web service authentication, here're the 3 ways I can >> > think >> > of: >> > 1. Use IIS IP restriction. Only allows certain IP to access service. >> >> There are a few problems with this one: >> >> a. The message won't be encrypted, so any sensitive data will >> potentially >> be exposed to eavesdroppers. >> b. IP addresses can be spoofed. >> c. Clients with dynamic IP addresses won't be able to connect (unless >> you >> remap to their new addresses, which adds a potential attack point). >> >> >> > 2. Use Certificate. This involves a fee to get the certificate for >> > server >> > and client. >> >> Not necessarily. For the server, a commercial certificate would probably >> be >> a good idea, but you could use a self-issued certificate if you're dead >> set >> against paying for one. Of course, convincing your client to trust your >> self-issued certificate would be a whole other story... >> >> It isn't necessary to use client certificates for authentication just >> because you're using a server certificate for other purposes (e.g.: SSL). >> If you do want to use client certificates for authentication, you could >> issue them yourself. After all, you're the only one who needs to trust >> them. >> >> As a bit of a side note, regardless of what other mechanisms you may >> select >> for encryption and/or authentication, applying a server certificate and >> enforcing the use of HTTPS when calling your web service over the >> internet >> would be good way to enhance the security of the system reasonably >> cheaply >> (both in terms of time and money). >> >> >> > 3. Use WSE2.0, web service enhancement toolkit. This can only be used >> > when >> > server and client are both using .net framework 1.1, both have to >> > install >> > the >> > toolkit. >> >> Not true. WSE renders web service messages that are supposed to be >> compliant with the WS-* standards. Depending on the tools available to >> your >> clients, they may find supporting these standards to be somewhat more or >> less difficult than it is via WSE. You should probably discuss this with >> them. >> >> >> > Am I understanding it right? What're the pros and cons of the >> > approaches? >> > And... are there any other ways? >> >> Yes. There are quite a few possible combinations of authentication and >> encryption schemes. Your best bet may be to take a look at >> http://msdn.microsoft.com/webservices/building/interop/ in order to >> target >> your research at the scenario you need to support. >> >> >> >> > I am now writing my service in .net, and my intended client is using >> > java >> > on >> > unix. >> > >> > Thanks a lot! >> > >> > >> > "GoCMS" wrote: >> > >> >> Hi, there: >> >> This might be a newbie question. I want my web service to require a >> >> certificate to access, so I go to IIS my virtual directory property >> >> and >> >> Directory Security page. I found the "secure communication" secion >> >> including >> >> "Server certificate" button are both greyed out. I wonder why that is. >> >> I'm an >> >> admin user of the computer. Did I miss some OS component or something? >> >> >> >> >> >> >>
Here's a bit of information on generating your own self-signed SSL server
certificate: http://www.jensign.com/JavaScience/dotnet/SSLCapicom/index.html (some links at bottom of page for some issues). Issuing client SSL certs is probably best done using MS CA, but if you only have a limited number of clients, you can easily roll your own SSL client certs .. which has some advantages. If you get commercial (say VeriSign) personal certs to use for SSL client authentication, they will only be valid for a year .. Depending on your level of paranoia and security concerns on your intranet, you could easily roll your own client cers with say 3 year validity period. Cheers, - Mitch Gallant MVP Security [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:OC5ZWmGNFHA.2468@tk2msftngp13.phx.gbl... > For an intranet-only application, use of an internally generated server > certificate would probably be OK as well. For generating the client and/or > server certificates, the first step would be to determine whether there is > already a CA (certification authority) running on the network. The best way > to do this would be to ask the network infrastructure folks in IT. > > If there is no CA in place already, then it would be necessary to set one up > if certificates are to be generated internally. Since the same network > infrastructure folks would presumably be responsible for its setup and > maintenance, this should be planned with them. If they have no other use > for an internal CA, it might be cheaper and easier to buy the certificates. > However, if they do want to set up a CA and are already running Windows > servers, the Microsoft CA would be a reasonable choice. For documentation > on the Microsoft CA, see > http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_cs_topnode.asp. > > > > "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message > news:08480628-9790-4BDE-88B4-1EF075D57631@microsoft.com... > > Hi, Nicole: > > Thanks a lot of your reply. My web service is going to be used only in > > intranet, so this is a lot easier to handle. It's just the caller will be > > java on unix. About the WSE 2.0 approach, it requires my caller to install > > a > > java plugin, and that makes it harder. I am thinking of the certificate > > method. How to generate and install a free client certificate. > > Thanks! > > > > "Nicole Calinoiu" wrote: > > > >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message > >> news:9DDDB619-71FB-4793-A582-8EF48217255B@microsoft.com... > >> > Thanks! I got it. ( thought the link for list of authorities to issue > >> > certificate doesn't really work for the last step. ) > >> > > >> > Anyway, about the web service authentication, here're the 3 ways I can > >> > think > >> > of: > >> > 1. Use IIS IP restriction. Only allows certain IP to access service. > >> > >> There are a few problems with this one: > >> > >> a. The message won't be encrypted, so any sensitive data will > >> potentially > >> be exposed to eavesdroppers. > >> b. IP addresses can be spoofed. > >> c. Clients with dynamic IP addresses won't be able to connect (unless > >> you > >> remap to their new addresses, which adds a potential attack point). > >> > >> > >> > 2. Use Certificate. This involves a fee to get the certificate for > >> > server > >> > and client. > >> > >> Not necessarily. For the server, a commercial certificate would probably > >> be > >> a good idea, but you could use a self-issued certificate if you're dead > >> set > >> against paying for one. Of course, convincing your client to trust your > >> self-issued certificate would be a whole other story... > >> > >> It isn't necessary to use client certificates for authentication just > >> because you're using a server certificate for other purposes (e.g.: SSL). > >> If you do want to use client certificates for authentication, you could > >> issue them yourself. After all, you're the only one who needs to trust > >> them. > >> > >> As a bit of a side note, regardless of what other mechanisms you may > >> select > >> for encryption and/or authentication, applying a server certificate and > >> enforcing the use of HTTPS when calling your web service over the > >> internet > >> would be good way to enhance the security of the system reasonably > >> cheaply > >> (both in terms of time and money). > >> > >> > >> > 3. Use WSE2.0, web service enhancement toolkit. This can only be used > >> > when > >> > server and client are both using .net framework 1.1, both have to > >> > install > >> > the > >> > toolkit. > >> > >> Not true. WSE renders web service messages that are supposed to be > >> compliant with the WS-* standards. Depending on the tools available to > >> your > >> clients, they may find supporting these standards to be somewhat more or > >> less difficult than it is via WSE. You should probably discuss this with > >> them. > >> > >> > >> > Am I understanding it right? What're the pros and cons of the > >> > approaches? > >> > And... are there any other ways? > >> > >> Yes. There are quite a few possible combinations of authentication and > >> encryption schemes. Your best bet may be to take a look at > >> http://msdn.microsoft.com/webservices/building/interop/ in order to > >> target > >> your research at the scenario you need to support. > >> > >> > >> > >> > I am now writing my service in .net, and my intended client is using > >> > java > >> > on > >> > unix. > >> > > >> > Thanks a lot! > >> > > >> > > >> > "GoCMS" wrote: > >> > > >> >> Hi, there: > >> >> This might be a newbie question. I want my web service to require a > >> >> certificate to access, so I go to IIS my virtual directory property > >> >> and > >> >> Directory Security page. I found the "secure communication" secion > >> >> including > >> >> "Server certificate" button are both greyed out. I wonder why that is. > >> >> I'm an > >> >> admin user of the computer. Did I miss some OS component or something? > >> >> > >> >> > >> > >> > >> > >
[quoted text, click to view]
"Michel Gallant" <neutron@istar.ca> wrote in message news:OcHdNtHNFHA.3844@TK2MSFTNGP14.phx.gbl... > Here's a bit of information on generating your own self-signed SSL server > certificate: Would you really recommend this for a _production_ intranet server? Sooner or later, someone else may want to connect to some other page on the site via HTTPS, and they almost certainly shouldn't end up using a makecert-generated certificate even if OP would consider one to be sufficient for the web service in question. [quoted text, click to view] > http://www.jensign.com/JavaScience/dotnet/SSLCapicom/index.html
> (some links at bottom of page for some issues). > > Issuing client SSL certs is probably best done using MS CA, but if you > only have a limited number of clients, you can easily roll your own > SSL client certs .. which has some advantages. If you get commercial (say > VeriSign) > personal certs to use for SSL client authentication, they will only be > valid > for a year .. > Depending on your level of paranoia and security concerns on your > intranet, > you could easily roll your own client cers with say 3 year validity > period. > > Cheers, > - Mitch Gallant > MVP Security > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:OC5ZWmGNFHA.2468@tk2msftngp13.phx.gbl... >> For an intranet-only application, use of an internally generated server >> certificate would probably be OK as well. For generating the client >> and/or >> server certificates, the first step would be to determine whether there >> is >> already a CA (certification authority) running on the network. The best >> way >> to do this would be to ask the network infrastructure folks in IT. >> >> If there is no CA in place already, then it would be necessary to set one >> up >> if certificates are to be generated internally. Since the same network >> infrastructure folks would presumably be responsible for its setup and >> maintenance, this should be planned with them. If they have no other use >> for an internal CA, it might be cheaper and easier to buy the >> certificates. >> However, if they do want to set up a CA and are already running Windows >> servers, the Microsoft CA would be a reasonable choice. For >> documentation >> on the Microsoft CA, see >> http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_cs_topnode.asp. >> >> >> >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message >> news:08480628-9790-4BDE-88B4-1EF075D57631@microsoft.com... >> > Hi, Nicole: >> > Thanks a lot of your reply. My web service is going to be used only in >> > intranet, so this is a lot easier to handle. It's just the caller will >> > be >> > java on unix. About the WSE 2.0 approach, it requires my caller to >> > install >> > a >> > java plugin, and that makes it harder. I am thinking of the certificate >> > method. How to generate and install a free client certificate. >> > Thanks! >> > >> > "Nicole Calinoiu" wrote: >> > >> >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message >> >> news:9DDDB619-71FB-4793-A582-8EF48217255B@microsoft.com... >> >> > Thanks! I got it. ( thought the link for list of authorities to >> >> > issue >> >> > certificate doesn't really work for the last step. ) >> >> > >> >> > Anyway, about the web service authentication, here're the 3 ways I >> >> > can >> >> > think >> >> > of: >> >> > 1. Use IIS IP restriction. Only allows certain IP to access service. >> >> >> >> There are a few problems with this one: >> >> >> >> a. The message won't be encrypted, so any sensitive data will >> >> potentially >> >> be exposed to eavesdroppers. >> >> b. IP addresses can be spoofed. >> >> c. Clients with dynamic IP addresses won't be able to connect (unless >> >> you >> >> remap to their new addresses, which adds a potential attack point). >> >> >> >> >> >> > 2. Use Certificate. This involves a fee to get the certificate for >> >> > server >> >> > and client. >> >> >> >> Not necessarily. For the server, a commercial certificate would >> >> probably >> >> be >> >> a good idea, but you could use a self-issued certificate if you're >> >> dead >> >> set >> >> against paying for one. Of course, convincing your client to trust >> >> your >> >> self-issued certificate would be a whole other story... >> >> >> >> It isn't necessary to use client certificates for authentication just >> >> because you're using a server certificate for other purposes (e.g.: >> >> SSL). >> >> If you do want to use client certificates for authentication, you >> >> could >> >> issue them yourself. After all, you're the only one who needs to >> >> trust >> >> them. >> >> >> >> As a bit of a side note, regardless of what other mechanisms you may >> >> select >> >> for encryption and/or authentication, applying a server certificate >> >> and >> >> enforcing the use of HTTPS when calling your web service over the >> >> internet >> >> would be good way to enhance the security of the system reasonably >> >> cheaply >> >> (both in terms of time and money). >> >> >> >> >> >> > 3. Use WSE2.0, web service enhancement toolkit. This can only be >> >> > used >> >> > when >> >> > server and client are both using .net framework 1.1, both have to >> >> > install >> >> > the >> >> > toolkit. >> >> >> >> Not true. WSE renders web service messages that are supposed to be >> >> compliant with the WS-* standards. Depending on the tools available >> >> to >> >> your >> >> clients, they may find supporting these standards to be somewhat more >> >> or >> >> less difficult than it is via WSE. You should probably discuss this >> >> with >> >> them. >> >> >> >> >> >> > Am I understanding it right? What're the pros and cons of the >> >> > approaches? >> >> > And... are there any other ways? >> >> >> >> Yes. There are quite a few possible combinations of authentication >> >> and >> >> encryption schemes. Your best bet may be to take a look at >> >> http://msdn.microsoft.com/webservices/building/interop/ in order to >> >> target >> >> your research at the scenario you need to support. >> >> >> >> >> >> >> >> > I am now writing my service in .net, and my intended client is using >> >> > java >> >> > on >> >> > unix. >> >> > >> >> > Thanks a lot! >> >> > >> >> > >> >> > "GoCMS" wrote: >> >> > >> >> >> Hi, there: >> >> >> This might be a newbie question. I want my web service to require >> >> >> a >> >> >> certificate to access, so I go to IIS my virtual directory property >> >> >> and >> >> >> Directory Security page. I found the "secure communication" secion >> >> >> including >> >> >> "Server certificate" button are both greyed out. I wonder why that >> >> >> is. >> >> >> I'm an >> >> >> admin user of the computer. Did I miss some OS component or >> >> >> something? >> >> >>
Depends on how your have your server client certificate trust list
created and how many users you have .. i.e. how manageable your infrastruct is. You obviously need to architect against your enterprise requirements, and a lot of careful planning in early days will save you headaches downstream. I have worked on several scenarios and it really depends on the specifics of your intranet .. future plans .. external access etc.. - Mitch [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:u1AoVcINFHA.204@TK2MSFTNGP15.phx.gbl...
> "Michel Gallant" <neutron@istar.ca> wrote in message > news:OcHdNtHNFHA.3844@TK2MSFTNGP14.phx.gbl... > > Here's a bit of information on generating your own self-signed SSL server > > certificate: > > Would you really recommend this for a _production_ intranet server? Sooner > or later, someone else may want to connect to some other page on the site > via HTTPS, and they almost certainly shouldn't end up using a > makecert-generated certificate even if OP would consider one to be > sufficient for the web service in question. > > > > > http://www.jensign.com/JavaScience/dotnet/SSLCapicom/index.html > > (some links at bottom of page for some issues). > > > > Issuing client SSL certs is probably best done using MS CA, but if you > > only have a limited number of clients, you can easily roll your own > > SSL client certs .. which has some advantages. If you get commercial (say > > VeriSign) > > personal certs to use for SSL client authentication, they will only be > > valid > > for a year .. > > Depending on your level of paranoia and security concerns on your > > intranet, > > you could easily roll your own client cers with say 3 year validity > > period. > > > > Cheers, > > - Mitch Gallant > > MVP Security > > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > > news:OC5ZWmGNFHA.2468@tk2msftngp13.phx.gbl... > >> For an intranet-only application, use of an internally generated server > >> certificate would probably be OK as well. For generating the client > >> and/or > >> server certificates, the first step would be to determine whether there > >> is > >> already a CA (certification authority) running on the network. The best > >> way > >> to do this would be to ask the network infrastructure folks in IT. > >> > >> If there is no CA in place already, then it would be necessary to set one > >> up > >> if certificates are to be generated internally. Since the same network > >> infrastructure folks would presumably be responsible for its setup and > >> maintenance, this should be planned with them. If they have no other use > >> for an internal CA, it might be cheaper and easier to buy the > >> certificates. > >> However, if they do want to set up a CA and are already running Windows > >> servers, the Microsoft CA would be a reasonable choice. For > >> documentation > >> on the Microsoft CA, see > >> http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_cs_topnode.asp. > >> > >> > >> > >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message > >> news:08480628-9790-4BDE-88B4-1EF075D57631@microsoft.com... > >> > Hi, Nicole: > >> > Thanks a lot of your reply. My web service is going to be used only in > >> > intranet, so this is a lot easier to handle. It's just the caller will > >> > be > >> > java on unix. About the WSE 2.0 approach, it requires my caller to > >> > install > >> > a > >> > java plugin, and that makes it harder. I am thinking of the certificate > >> > method. How to generate and install a free client certificate. > >> > Thanks! > >> > > >> > "Nicole Calinoiu" wrote: > >> > > >> >> "GoCMS" <GoCMS@discussions.microsoft.com> wrote in message > >> >> news:9DDDB619-71FB-4793-A582-8EF48217255B@microsoft.com... > >> >> > Thanks! I got it. ( thought the link for list of authorities to > >> >> > issue > >> >> > certificate doesn't really work for the last step. ) > >> >> > > >> >> > Anyway, about the web service authentication, here're the 3 ways I > >> >> > can > >> >> > think > >> >> > of: > >> >> > 1. Use IIS IP restriction. Only allows certain IP to access service. > >> >> > >> >> There are a few problems with this one: > >> >> > >> >> a. The message won't be encrypted, so any sensitive data will > >> >> potentially > >> >> be exposed to eavesdroppers. > >> >> b. IP addresses can be spoofed. > >> >> c. Clients with dynamic IP addresses won't be able to connect (unless > >> >> you > >> >> remap to their new addresses, which adds a potential attack point). > >> >> > >> >> > >> >> > 2. Use Certificate. This involves a fee to get the certificate for > >> >> > server > >> >> > and client. > >> >> > >> >> Not necessarily. For the server, a commercial certificate would > >> >> probably > >> >> be > >> >> a good idea, but you could use a self-issued certificate if you're > >> >> dead > >> >> set > >> >> against paying for one. Of course, convincing your client to trust > >> >> your > >> >> self-issued certificate would be a whole other story... > >> >> > >> >> It isn't necessary to use client certificates for authentication just > >> >> because you're using a server certificate for other purposes (e.g.: > >> >> SSL). > >> >> If you do want to use client certificates for authentication, you > >> >> could > >> >> issue them yourself. After all, you're the only one who needs to > >> >> trust > >> >> them. > >> >> > >> >> As a bit of a side note, regardless of what other mechanisms you may > >> >> select > >> >> for encryption and/or authentication, applying a server certificate > >> >> and > >> >> enforcing the use of HTTPS when calling your web service over the > >> >> internet > >> >> would be good way to enhance the security of the system reasonably > >> >> cheaply > >> >> (both in terms of time and money). > >> >> > >> >> > >> >> > 3. Use WSE2.0, web service enhancement toolkit. This can only be > >> >> > used > >> >> > when > >> >> > server and client are both using .net framework 1.1, both have to > >> >> > install > >> >> > the > >> >> > toolkit. > >> >> > >> >> Not true. WSE renders web service messages that are supposed to be > >> >> compliant with the WS-* standards. Depending on the tools available > >> >> to > >> >> your > >> >> clients, they may find supporting these standards to be somewhat more > >> >> or > >> >> less difficult than it is via WSE. You should probably discuss this > >> >> with > >> >> them. > >> >> > >> >> > >> >> > Am I understanding it right? What're the pros and cons of the > >> >> > approaches? > >> >> > And... are there any other ways? > >> >> > >> >> Yes. There are quite a few possible combinations of authentication > >> >> and > >> >> encryption schemes. Your best bet may be to take a look at
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |