When dealing with SSL certificates in a CNAME-redirected environment, the key principle is: Your certificate's Common Name (CN) must match what users type in their browser's address bar. In your case, since users access the service via portal.company.com (the CNAME alias), this should be your certificate's primary name.

For your CSR generation, you have several options:

# Example OpenSSL CSR generation command
openssl req -new -newkey rsa:2048 -nodes -keyout portal.company.com.key \
-out portal.company.com.csr -subj "/CN=portal.company.com"

However, modern best practices recommend using Subject Alternative Names (SANs):

# Configuration file for SAN (req.conf):
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = California
L = San Francisco
O = Company Inc
CN = portal.company.com

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = portal.company.com
DNS.2 = portal.dlinkddns.com

When using a CNAME configuration:

• Certificate Authorities (CAs) will validate against the canonical name (portal.dlinkddns.com)
• But the certificate must include the alias (portal.company.com) as either CN or SAN
• For DV certificates, you'll need to prove control of both domains

Here's how to properly configure Apache with such certificate:

<VirtualHost *:443>
    ServerName portal.company.com
    ServerAlias portal.dlinkddns.com
    
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/private.key
    SSLCertificateChainFile /path/to/chain.pem
    
    # Your other configuration directives
</VirtualHost>

If you encounter SSL errors after implementation:

1. Verify certificate chain integrity: openssl verify -CAfile chain.pem cert.pem
2. Check name matching: openssl x509 -in cert.pem -noout -text | grep -E "DNS|CN"
3. Test connectivity: openssl s_client -connect portal.company.com:443 -servername portal.company.com

When dealing with CNAME records and SSL certificates, it's crucial to understand the DNS hierarchy. Your setup involves:

portal.company.com.    IN CNAME portal.dlinkddns.com.
portal.dlinkddns.com.  IN A     [dynamic IP]

Modern CAs follow strict validation rules. For your CSR:

• The Common Name (CN) must exactly match what users will type in browsers
• Subject Alternative Names (SANs) should include all valid access points
• Never use internal domain names (like .local) in public certificates

Here's how to generate your certificate request properly using OpenSSL:

openssl req -new -newkey rsa:2048 -nodes -keyout portal.key \
-out portal.csr -subj "/CN=portal.company.com" \
-addext "subjectAltName=DNS:portal.company.com,DNS:portal.dlinkddns.com"

Certificate validation fails when:

1. The CN doesn't match the browser's URL
2. SANs are missing alternate access methods
3. CNAME chains exceed the maximum allowed length

For Apache configuration:

<VirtualHost *:443>
    ServerName portal.company.com
    ServerAlias portal.dlinkddns.com
    
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/portal.crt
    SSLCertificateKeyFile /etc/ssl/private/portal.key
    SSLCertificateChainFile /etc/ssl/certs/intermediate.crt
    
    # Your remaining configuration...
</VirtualHost>

Consider these best practices:

• Set calendar reminders for certificate expiration
• Use ACME clients like Certbot for automatic renewal
• Monitor CNAME resolution with tools like Dig