Certificates have depths, which increase as you go down a trust chain, so certificate depth 0 issues certificate depth 1, which issues certificate depth 2, etc...
To satisfactorily verify a full certificate chain, a client connecting to your SSL secured website would have to be able to find the intermediaries, and verify them, until it reaches a trusted certificate, which under any normal circumstances is a CA certificate installed with your OS.
An arbitrary client would not find your intermediary certificate in this case, because it will be equipped with all the usual certificates installed with the OS, but of course, it won't have your intermediary...
A desktop computer, or server, built as part of some sort of special corporate build for the company, can of course be tampered with, by adding certificates, and some companies do this, adding their own root CA with all the other default ones.
Your SSL secured web server can however provide intermediate certificates (along with its own) to the client when it connects so that it can complete the chained trust verification process, but...
The next problem is the intermediate certificate, the one issued to you by your CA, may not be valid as a CA itself, and if so it won't be accepted as an intermediate certificate.
Using openssl you can check this by running 'openssl x509':
openssl x509 -text -in CERT_FILENAME
Trying this on a CA certificate, looking through the output, you can see:
ef:47:91:0a:72:ba:9e:85:3c:7e:39:6b:62:ed:d0:
13:53:cf:52:52:e2:a8:1a:a8:27:5c:7e:08:a2:ad:
17:1d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4
X509v3 Authority Key Identifier:
keyid:5C:FC:C1:89:C0:DC:DD:C7:01:0D:EA:37:73:A8:7B:F4:55:85:A5:E4
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
17:e4:1d:18:d6:43:68:75:04:11:c0:6f:72:6b:ac:eb:03:18:
1c:f3:e3:94:f8:77:b5:40:38:3b:20:cd:42:d7:de:db:7c:98:
The magic bit that you are looking for is:
CA:TRUE
If CA is FALSE or the x509 extensions aren't there, it's not going to work as an intermediate CA.
Finally, also if you have openssl, you can do "openssl s_client -connect som.ssl.web.site:443 -CApath /path/to/your/CAcerts -verify 5", and hopefully you should, near the end of a load of output, get:
Verify return code: 0 (ok)
Where your intermediate is not valid as a CA though, you will get:
Verify return code: 26 (unsupported certificate purpose)
I tested this generating a CA, then an intermediate certificate, and an 'end' certificate signed by the intermediate, and although the chain of trust is verifiable successfully, used on a website, it does not work. If I generate a V3 intermediate with x509 extensions, setting the basic constraints of CA to TRUE, and then generate an 'end' certificate signed by that, again the trust chain is fine, but this time the web client is happy.