2009-04-03 19 views
11

Tengo un sitio web (www.midominio.com) que está protegido con un certificado SSL. Es un sitio web de ASP.NET y he obligado a ciertas páginas a través del código a usar el prefijo https: //. Si no lo hacen, los redireccionará al https: // equivalente. ¿Es esta una buena practica? ¿Hay alguna forma más fácil de hacer esto? No todas las páginas requieren SSL.Buenas prácticas del sitio web con protección SSL

Además, cuando los usuarios usan mi URL en forma de midominio.com en lugar de www.midominio.com, reciben un error de certificado porque el certificado fue registrado para www.midominio.com. ¿Debería utilizar el mismo enfoque que con el problema http: // y https: // que mencioné anteriormente? ¿O hay una mejor manera de manejar esto?

Respuesta

2

Su enfoque suena bien. En mi proyecto actual, fuerzo HTTPS cuando un usuario va a mi página de inicio de sesión (basado en un indicador de configuración que me permite realizar pruebas locales sin tener que lidiar con la necesidad de un certificado). Esto me permite acceder a otras páginas no aseguradas, lo cual es útil.

Tengo un par de lugares en los que nuestro servidor capta el resultado de otras páginas (por ejemplo, la representación en html a PDF y la obtención de imágenes dinámicas). Debido a nuestro entorno, nuestro servidor no puede resolver su nombre público, por lo que si tuviéramos que forzar ssl en el sitio, tendríamos que agregar nuestra dirección IP interna (o falsificar el nombre de dominio).

En cuanto a su segunda pregunta, tiene dos opciones para manejar www.example.com vs example.com. Puede comprar un certificado que le permita tener múltiples nombres de dominio. Estos se conocen como certificados UCC.

Su segunda opción es redirigir example.com a www.example.com o al revés. Redirigir es una gran opción si desea que su contenido sea indexado por google u otros motores de búsqueda. Ya que verán www.example.com y example.com como dos sitios separados. Esto significa que los enlaces a sus sitios se dividirán reduciendo su rango general de páginas.

+0

Sí, tomo el mismo enfoque. Tengo una clave EnableSsl en mi archivo web.config que puedo activar y desactivar dependiendo del entorno en el que me encuentre. También tengo una clave SecurePages delimitada por tuberías a la que puedo agregar/eliminar sitios fácilmente. –

+0

Otra forma en lugar de delimitada por Tuberías (suponiendo que no necesita cambiar esto después de implementar) sería definir una página base que haga la verificación, entonces cualquier página que quiera garantizar segura heredará siempre de esa página. También puedes usar atributos. – JoshBerke

+0

Sí, pero preferiría tener una única página base, y me gustaría tener la capacidad de establecer dinámicamente las páginas en SSL o no sin recompilar. –

1

Puede configurar sitios en IIS para solicitar un certificado pero eso A) generará un error si alguien no está visitando con https y B) requerirá que todas las páginas usen https. Por lo tanto, que no funcionará. Podría poner un filtro en IIS que verifique todas las solicitudes y las redirija como llamadas https si están en su lista de encriptación. El inconveniente obvio aquí es la necesidad de actualizar su lista de páginas cada vez que se agrega una nueva página (por ejemplo, desde un archivo XML o base de datos) y reiniciar el filtro.

Creo que probablemente tenga razón en la creación de código en las páginas que requieren https que redirigen a una versión https si llegan a través de http. En lo que respecta a su error de certificación, puede redireccionar con una ruta completa (que incluye www) en lugar de una ruta relativa para solucionar este problema. Si tiene alguna pregunta sobre cómo detectar si la llamada usa https O cómo obtener la ruta completa de la solicitud actual, por favor hágamelo saber. Ambos son bastante sencillos, pero tengo un código de muestra si lo necesitas.

ACTUALIZACIÓN - Josh, los certs que manejan múltiples subdominios se llaman certificados comodín. El problema es que son bastante más caros que los certificados estándar.

ACTUALIZACIÓN 2: Otra cosa a considerar es utilizar una página maestra o una clase derivada para las páginas que necesitan SSL. De esta forma, en lugar de duplicar el código en cada página, simplemente puede declararlo como tipo SSLPage (o usar la página maestra correspondiente) y hacer que la clase Master/Parent maneje la redirección. De nuevo, necesitará hacer algún procesamiento de URL si toma este enfoque, pero es bastante trivial.

+0

Gracias por su contribución. Ya estoy detectando para http: // y https: //, así que eso no será un problema. Tendré que jugar con buscar www. porque la url no tendrá eso en mi máquina de desarrollo. ¿Algún consejo? –

+0

Marcar ahora se llaman certificados UCC. Los comodines son diferentes. Un UCC de Godaddy que puede admitir 5 dominios es de $ 89/año. – JoshBerke

+0

Mike: Agregue la entrada www.localhost a su archivo de hosts. Esto le permitirá probar su www. lógica :-) – JoshBerke

-1

que sigue es algo que puede ayudarle a:

  • Si está bien para mostrar todas sus páginas web con https: // A continuación, puede actualizar el código para utilizar https: // y establecer dos fijaciones en IIS. Uno es para http y otro es para https. De esta manera, su sitio web puede ser accesible a través de cualquiera de los protocolos.
  • Sus visitantes reciben un error de coincidencia de nombre porque el nombre común utilizado en su certificado SSL es www.midominio.com. Namecheap proporciona certificados RapidSSL a través de los cuales puede proteger ambos nombres bajo SSL único. Puede comprar este SSL para www.midominio.com y automáticamente protegerá mydomain.com (es decir, sin www).

Otra opción es escribir un código para redirigir a los visitantes al sitio web www.mydomain.com incluso si navegan en mydomain.com.

Cuestiones relacionadas