This guide explains how to create a self-signed wildcard SSL certificate for internal use. A wildcard SSL certificate allows you to secure a domain and all its subdomains with a single certificate. These certificates are ideal for development, staging, and internal systems where a trusted Certificate Authority (CA) is not required.<\/p>\n
These commands are compatible with OpenSSL 1.1.1 and above, typically found on Ubuntu, Debian, CentOS, RHEL, Rocky Linux, and AlmaLinux.<\/p>\n
Modern browsers and servers require Subject Alternative Name (SAN) fields. This method ensures maximum compatibility.<\/p>\n
[ req ]\r\ndefault_bits\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = 2048\r\nprompt\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = no\r\ndefault_md\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = sha256\r\nreq_extensions\u00a0\u00a0\u00a0\u00a0 = req_ext\r\ndistinguished_name = dn\r\n\r\n[ dn ]\r\nC\u00a0 = US\r\nST = State\r\nL\u00a0 = City\r\nO\u00a0 = Company\r\nOU = IT\r\nCN = *.example.com\r\n\r\n[ req_ext ]\r\nsubjectAltName = @alt_names\r\n\r\n[ alt_names ]\r\nDNS.1 = *.example.com\r\nDNS.2 = example.com\r\n\r\n<\/pre>\nReplace fields as required and update the domain name.<\/li>\n
openssl req -new -nodes -out wildcard.csr -keyout wildcard.key -config san.cnf<\/pre>\n<\/li>\n
openssl x509 -req -days 365 -in wildcard.csr -signkey wildcard.key \\ -extfile san.cnf -extensions req_ext -out wildcard.crt<\/pre>\n<\/li>\n
openssl req -newkey rsa:2048 -nodes -keyout wildcard.key -out wildcard.csr \\\r\n-subj \u201c\/C=US\/ST=State\/L=City\/O=Company\/OU=IT\/CN=*.example.com\u201d<\/pre>\n<\/li>\n
openssl x509 -req -days 365 -in wildcard.csr -signkey wildcard.key -out wildcard.crt<\/pre>\nNote: This method does not include SAN and may trigger warnings in modern browsers and applications.<\/li>\n<\/ol>\n
Installing the SSL Certificate<\/strong><\/h3>\n
\n
- Apache Example
\nAdd the following to your SSL VirtualHost:<\/p>\nSSLEngine on\r\nSSLCertificateFile \/path\/to\/wildcard.crt\r\nSSLCertificateKeyFile \/path\/to\/wildcard.key<\/pre>\n<\/li>\n- Restart Apache:\n
systemctl restart apache2<\/pre>\n<\/li>\n- Nginx Example
\nAdd to your server block:<\/p>\nssl_certificate \/path\/to\/wildcard.crt;\r\nssl_certificate_key \/path\/to\/wildcard.key;<\/pre>\n<\/li>\n- Restart <\/a>Nginx:\n
systemctl restart nginx<\/pre>\n<\/li>\n<\/ol>\nOptional: Generate PFX File (For Windows\/IIS)<\/strong><\/p>\n
openssl pkcs12 -export -out wildcard.pfx -inkey wildcard.key -in wildcard.crt<\/pre>\nImportant Notes<\/strong><\/h3>\n
\n
- Web browsers refuse to accept self-signed wildcard SSL certificates and show a warning.<\/li>\n
- One level of subdomains, such as site.example.com, is covered by wildcard certificates, but not a.b.example.com.<\/li>\n
- For production use, always obtain certificates from a trusted Certificate Authority (CA).<\/li>\n<\/ul>\n
Creating a self-signed wildcard SSL certificate is a fast and free way to secure many subdomains while you are developing or testing a website. But, for live\/production websites, you should always use an SSL certificate issued by a trusted Certificate Authority (CA).<\/p>\n
Managing SSL certificates and securing multiple subdomains?<\/strong>
\nA Windows VPS Hosting<\/a> solution provides administrator access and the flexibility needed to manage SSL certificates, IIS settings and secure business websites.<\/div>\n