# Estado de Dominios y Subdominios - xgestion.com.ar

**Fecha**: 30 de Mayo de 2026  
**Certificado SSL**: ✅ Emitido y configurado en ACM

## Certificado SSL

- **ARN**: arn:aws:acm:us-east-1:788424700802:certificate/fce3845c-d520-4d7a-92b0-87f4f5b90e3e
- **Estado**: ISSUED ✅
- **Dominios cubiertos**:
  - xgestion.com.ar
  - *.xgestion.com.ar
  - www.xgestion.com.ar
- **Renovación**: Automática por AWS ACM

## Configuración DNS Actual

### ✅ Apuntan al Load Balancer (con SSL válido):

| Dominio | Tipo | Destino | Estado |
|---------|------|---------|--------|
| xgestion.com.ar | A (Alias) | LB-VerenaPay | ✅ Configurado |
| *.xgestion.com.ar | A (Alias) | LB-VerenaPay | ✅ Configurado |
| www.xgestion.com.ar | CNAME | xgestion.com.ar | ✅ Configurado |

### ⚠️ Subdominios específicos (todavía apuntan a IP directa):

Estos subdominios tienen registros DNS específicos que tienen prioridad sobre el wildcard:

| Subdominio | IP Actual | Nota |
|------------|-----------|------|
| app.xgestion.com.ar | 34.199.75.144 | Apunta directo al EC2 |
| docs.xgestion.com.ar | 34.199.75.144 | Apunta directo al EC2 |
| labs.xgestion.com.ar | 34.199.75.144 | Apunta directo al EC2 |
| phpmyadmin.xgestion.com.ar | 34.199.75.144 | Apunta directo al EC2 |
| web.xgestion.com.ar | 34.199.75.144 | Apunta directo al EC2 |

**Impacto**: Estos subdominios seguirán usando el certificado expirado del servidor EC2 hasta que se eliminen sus registros DNS específicos o se actualicen al Load Balancer.

### ✅ Subdominios de correo (NO modificar):

| Subdominio | IP | Nota |
|------------|-----|------|
| mail.xgestion.com.ar | 34.207.39.54 | Servidor de correo separado |
| webmail.xgestion.com.ar | 34.207.39.54 | Servidor de correo separado |

## Load Balancer Configuration

- **Load Balancer**: LB-VerenaPay
- **DNS**: LB-VerenaPay-468402085.us-east-1.elb.amazonaws.com
- **Target Group**: xGestion-TargetGroup
- **Instancia**: i-082f9c9601aa4bd15 (34.199.75.144)
- **Health Check**: Configurado para aceptar códigos HTTP 200-499
- **Estado actual**: ⚠️ Unhealthy (el servidor responde con error 500)

### Reglas de enrutamiento:

- **Prioridad**: 10
- **Condición**: Host header = xgestion.com.ar, *.xgestion.com.ar, www.xgestion.com.ar
- **Acción**: Forward a xGestion-TargetGroup
- **Listeners**: HTTP (80) y HTTPS (443)

## Funcionamiento Actual

### ✅ Funcionan con SSL válido:
- xgestion.com.ar (a través del Load Balancer)
- www.xgestion.com.ar (a través del Load Balancer)
- Cualquier subdominio NO listado específicamente en DNS (usa wildcard)

### ⚠️ Todavía con certificado expirado:
- app.xgestion.com.ar
- docs.xgestion.com.ar
- labs.xgestion.com.ar
- phpmyadmin.xgestion.com.ar
- web.xgestion.com.ar

## Solución para subdominios específicos

Para que TODOS los subdominios usen el certificado válido, hay 2 opciones:

### Opción 1: Eliminar registros DNS específicos (Recomendado)

Esto hará que usen el wildcard (*.xgestion.com.ar) que apunta al Load Balancer:

```bash
# Eliminar cada subdominio específico
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1DQ5U0D1VV4BJ \
  --change-batch '{
    "Changes": [
      {"Action": "DELETE", "ResourceRecordSet": {"Name": "app.xgestion.com.ar.", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "34.199.75.144"}]}},
      {"Action": "DELETE", "ResourceRecordSet": {"Name": "docs.xgestion.com.ar.", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "34.199.75.144"}]}},
      {"Action": "DELETE", "ResourceRecordSet": {"Name": "labs.xgestion.com.ar.", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "34.199.75.144"}]}},
      {"Action": "DELETE", "ResourceRecordSet": {"Name": "phpmyadmin.xgestion.com.ar.", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "34.199.75.144"}]}},
      {"Action": "DELETE", "ResourceRecordSet": {"Name": "web.xgestion.com.ar.", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "34.199.75.144"}]}}
    ]
  }' \
  --profile xgestion \
  --region us-east-1
```

### Opción 2: Actualizar cada subdominio al Load Balancer

Cambiar cada registro para que apunte al Load Balancer en lugar de la IP directa.

## Estado del Servidor EC2

⚠️ **El servidor está respondiendo con error 500**

Esto es un problema de la aplicación, no de la configuración del certificado o Load Balancer. El servidor está:
- ✅ Accesible desde el Load Balancer
- ✅ Respondiendo en el puerto 80
- ⚠️ Devolviendo error 500 (Internal Server Error)

**Posibles causas**:
1. Error de configuración de la aplicación PHP
2. Problema con la base de datos
3. Permisos de archivos
4. Configuración de Apache/Nginx

**Verificación necesaria**:
```bash
# Conectarse al servidor y revisar logs
ssh ec2-user@34.199.75.144
sudo tail -f /var/log/apache2/error.log
# o
sudo tail -f /var/log/httpd/error_log
```

## Resumen

| Componente | Estado | Notas |
|------------|--------|-------|
| Certificado SSL | ✅ Válido | Renovación automática |
| Load Balancer | ✅ Configurado | Múltiples certificados (SNI) |
| DNS Principal | ✅ Actualizado | Apunta al Load Balancer |
| DNS Wildcard | ✅ Actualizado | Apunta al Load Balancer |
| Subdominios específicos | ⚠️ Pendiente | Todavía usan IP directa |
| Servidor EC2 | ⚠️ Error 500 | Requiere revisión de logs |
| Target Group | ⚠️ Unhealthy | Por error 500 del servidor |

## Próximos pasos recomendados

1. **Urgente**: Revisar logs del servidor EC2 para solucionar el error 500
2. **Opcional**: Eliminar registros DNS específicos de subdominios para que usen el wildcard
3. **Monitoreo**: Verificar que el Target Group pase a "healthy" una vez solucionado el error 500

---

**Última actualización**: 30 de Mayo de 2026