The encryption is not a property of the certificate or where it is signed from. The benefit you get from a CA signed cert is that it is automatically trusted by web browsers (and other SSL-aware applications). A self-signed certificate will pop up a warning that the certificate is not trusted. In more recent browsers, such as FireFox 3, the default action is to refuse to show the page and the user has to take deliberate actions to enable use of a self-signed (or expired, for that matter) certificate.
If you can talk to everyone who will use the web page (if this is for your family only, for example), this isn't a problem. Tell them to expect that warning and how to handle it in their browser and it's a one-time issue.
However, if this is for any use that requires anything approaching real security, you probably want a true, signed, not self-signed certificate.
The following should work for you:
cp /etc/ssl/openssl.cnf /tmp/
echo '[ subject_alt_name ]' >> /tmp/openssl.cnf
echo 'subjectAltName = DNS:www.example.com, DNS:site1.example.com, DNS:site2.example.com' >> /tmp/openssl.cnf
openssl req -x509 -nodes -newkey rsa:2048 \
-config /tmp/openssl.cnf \
-extensions subject_alt_name \
-keyout www.example.com.key \
-out www.example.com.pem \
-subj '/C=XX/ST=XXXX/L=XXXX/O=XXXX/OU=XXXX/CN=www.example.com/emailAddress=postmaster@example.com'
Result:
$ openssl x509 -in www.example.com.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17965603478303142689 (0xf952a52d7bc7f321)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=XX, ST=XXXX, L=XXXX, O=XXXX, OU=XXXX, CN=www.example.com/emailAddress=flb.helpdesk@morpho.com
Validity
Not Before: Apr 3 15:34:27 2015 GMT
Not After : May 3 15:34:27 2015 GMT
Subject: C=XX, ST=XXXX, L=XXXX, O=XXXX, OU=XXXX, CN=www.example.com/emailAddress=flb.helpdesk@morpho.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c6:e8:17:93:a4:8f:08:11:61:11:1b:cc:17:52:
b6:33:39:33:0e:94:3f:ac:ae:dd:70:4b:e6:d6:b0:
11:f1:93:b4:3d:dc:34:99:27:b6:45:4b:13:0c:69:
1e:11:d2:b9:38:5f:e0:d1:b0:58:e4:3c:c0:9f:58:
3d:5d:fa:67:3e:3c:05:1b:e3:86:20:18:d5:d7:83:
77:b5:0c:1d:9a:26:96:10:3f:2c:e5:ce:ed:6e:99:
5a:35:3e:06:f0:52:aa:72:5e:c0:33:7c:c8:16:f9:
6b:3e:7d:7e:5a:1f:cf:11:63:4d:ad:bf:77:bd:e3:
0f:8f:24:1d:f5:c8:06:ab:d9:62:8d:13:56:62:a9:
b8:77:c0:11:b6:ff:a7:63:93:a7:22:c2:41:48:6f:
bd:42:10:00:33:14:da:3b:ca:e0:07:c2:b6:50:55:
f0:4d:6b:0d:eb:87:a8:bd:4d:c6:1b:20:d8:27:68:
d0:e2:3b:32:91:b8:8e:cf:25:06:bf:43:fd:8f:96:
fa:eb:af:0f:e1:5c:47:06:84:8b:f4:35:0a:a8:f3:
7e:af:34:50:7f:62:bc:5e:53:09:90:97:27:cf:9a:
56:d7:f6:af:32:92:c4:c9:ab:90:6e:a6:09:20:0b:
46:28:22:0b:45:71:b9:17:77:d8:da:63:24:27:5c:
60:a5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:site1.example.com, DNS:site2.example.com
Signature Algorithm: sha256WithRSAEncryption
83:ce:18:74:f9:17:92:91:bd:82:13:ac:64:e7:de:9e:38:d7:
26:0f:2d:3e:8f:f2:17:c5:fc:17:06:fb:27:e7:0a:b7:f2:8e:
bb:18:6e:f4:4c:17:e8:8d:dc:51:d5:d2:e6:1c:72:e4:28:75:
a2:79:ae:b6:b6:8c:ec:08:08:4d:73:79:b7:22:26:40:ac:38:
5c:f2:2b:4f:44:60:55:db:90:b3:63:74:ad:e7:26:12:ad:0d:
ec:4a:cd:4f:7a:a0:54:62:f5:a7:bc:80:c2:fa:34:43:3c:f1:
aa:f7:6e:4e:e1:80:fb:c7:cc:44:3a:2b:a4:6c:5b:0f:3f:83:
6e:8d:d5:28:cf:6c:f0:c6:40:4d:c4:d4:3f:9c:9d:a4:47:a7:
27:d1:5b:2b:5f:0d:bd:3f:7c:2e:19:fa:bc:24:bd:1f:64:81:
8b:a4:e3:33:10:35:55:f9:73:2d:8b:e8:b8:d7:e3:49:0c:35:
af:53:df:48:d8:df:ce:b1:5f:6c:74:1c:74:89:45:2e:28:2c:
1f:fe:d8:a4:44:9c:c7:bc:d8:6a:46:38:df:e3:d0:05:37:27:
d0:08:e5:93:b8:0e:d9:d9:dd:7c:28:75:18:27:be:4e:72:47:
13:b9:a2:93:0e:83:e9:b8:49:f4:75:ad:e0:0f:9b:e5:96:4f:
33:33:f1:27
If you want request instead of self-signed just replace -x509 with -new and -extensions with -reqexts.
Update
Subject Alternative Name can be specified directly in command line with the recent versions of openssl:
openssl req -x509 -nodes -newkey rsa:2048 \
-subj '/C=XX/ST=XXXX/L=XXXX/O=XXXX/OU=XXXX/CN=www.example.com/emailAddress=postmaster@example.com' \
-addext 'subjectAltName = DNS:www.example.com, DNS:site1.example.com, DNS:site2.example.com' \
-keyout www.example.com.key \
-out www.example.com.pem
See also https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-the-command-line/183973#183973
Best Answer
As a rule of thumb:
No, implied in trusting the customer's CA certificate is the trust in every certificate signed by that CA.
I don't know of any applications/libraries that have an easy option that allows you as the end-user to select that you'll trust your customers or any other CA certificate only for certain (sub-) domains i.e. only for *.example.com and *.example.org and nothing else.
Mozilla has a similar concern about currently trusted government sponsored CA's as an open attention point and for instance Chrome has extra checks built in for accessing Google sites, which was how the rogue *.google.com certificate and the compromise of the Diginotar CA became public.
But even if you don't trust the CA, you can still import/trust a specific server certificate signed by that CA, which will prevent SSL warnings for the hostnames in that certificate. That should make your application work without errors or complaints.
Exceptions:
A very underused option of the X.509v3 PKI standard is the Name Constraints extension, which allows a CA certificate to contain white- and blacklists of domain name patterns it is authorized to issue certificates for.
You might be lucky and your customer has restrained themselves when they set up their PKI infrastructure and included that Name constraint in their CA certificate. Then you can import their CA certificate directly and know that it can only validate a limited range of domain names.