Yes, it can be done as the two services are listening on different ports.
I'm not familiar with the specifics of doing so with either VSFTPD or Apache though sorry.
You just have to ensure both VSFTPD and Apache are using the same private key as well as the cert itself (and potentially any intermediate root certs that come in to play with your SSL certificate - if you didn't need to install one for apache, you shouldn't need to for VSFTPD either). Yes, the domain will have to be the same to avoid any cert errors.
Certificates are, regardless of what sales people say, objectively pretty much all the same with regards to encryption. They all enable 'good enough' encryption, which really mostly depends on the configuration of the web servers, and somewhat on the capabilities of the browser. The US ban on exporting strong encryption was lifted some years ago, so today pretty much all browsers will support a 128-bit Twofish or AES encryption, if the server proposes this. (Surprisingly many servers still use 56bit DES, RC4 or other weaker schemes, due to ignorance of the sysadmin, or to lower CPU load on the server.)
The problem of long daisy-chained certificate trust relationships is also pretty much gone. Most browsers today have a fairly complete set of pre-installed trusted CAs. Open your browsers cert UI to see yours (Firefox 3: Tools > Options > Advanced > Encryption > View Certificates).
From time to time you can find promotions where resellers offer Comodo, Digicert or similar certificates for ~20 USD or so.
The level of 'trust' your site inspires in customers may be a consideration. Arguably, a Verisign site seal and the green Extended Validation bar in compliant browsers is better than a simple 128 bit encryption with a certificate from GoDaddy. It's hard to tell, it will depend a lot on your user demographics, age, computer literacy et cetera.
One thing: It can be beneficial to keep your DNS Whois information accurate, as it is a big part of how CAs verify you before issuing a certificate. I would imagine that getting your certificate from someone you're already doing business with, such as your web host / DNS registrar, is easier than getting verified by Comodo, Thawte etc.
So my proposal is to asses your users, and whether a more 'trustworthy' branding on the site seal will create more sales. And then do one of the following:
- Get the cheapest 128 bit certificate you can from a reseller / DNS registrar / whoever with whom you already have an account. Maybe investigate briefly who signs the Cert, and what the root CA is, but don't sweat it unless it is a pretty obscure CA chain.
- Get a Verisign or similar well-known (and bloody expensive) SSL cert with good brand value, and display their site seal prominently. Consider going for an Extended Validation cert.
The "Extended Validation" certificates add some value IMHO, because the browsers visually assure users that everything is OK with the green address bar, prominent company name etc. Unfortunately, these certificates are also expensive, and more annoying to get validated for.
Best Answer
Sure, why shouldn't it? A server certificate identifies a host (by DNS name or IP), not a service. All services on a host can (IMHO even should) use the same certificate.