Client has wildcard SSL for his domain/subdomains.

The application we are building is on one of our linux servers using one of our IP addresses and is contained within an account named www.somedomain.com. Our plan was to set the SSL cert up on our server.

Client suggested we can use HIS wildcard SSL cert for the application/site. He suggested that all he needs is SHA2 on our server.

Will his SSL Certificate cause browsers to warn about the domains changing? The browser requests will always be made at his.subdomain.com and directed to www.somedomain.com via an A record and a parked domain on our server.

Do I in fact need the SSL for our server and domain?


2 Answers 2


Not certain I completely understood the question, but here goes:

If you have a valid cert for https://example.NET/, and you are in fact reachable via that FQDN, then you are free to redirect anywhere.

That's all there is to it. You can redirect to example.COM if you wish. HTTP or HTTPS. Your choice. But if you want to do HTTPS, then you need a cert that is valid for that FQDN. (The cert for example.net will not work when deployed to example.com.)

  • Thanks, So using his wildcard SSL he can redirect his new subdomain which he created for this app - which points via A record to our server IP - where I have his subdomain parked on the account www.somedomain.com
    – james-ef
    Oct 16, 2015 at 20:02
  • A browser should not care about the IP. Only if DNS matches certs found there. Oct 17, 2015 at 4:04

First, an A record can only point to an IP address, not a hostname.

Secondly, once the clients hit that IP address - which seems to be your own server - it needs to have a valid certificate for the hostname requested (his.subdomain.com would need *.subdomain.com). Obviously, you need your server to answer for this hostname/vhost.

www.somedomain.com doesn't have anything to do in this picture.

Also, SHA2 is a different topic and has nothing to do with the vhost setup. This relates to the signature of the certificate which you don't own and have no control over.

To correctly understand all those elements, I suggest referring to the OSI model. Being able to abstract complexity of different layers is extremely useful to correctly understand the big picture without mixing concepts from different technology altogether.

  • Thanks for the response. My clients' subdomain (which will point va A record to our server IP) is the only one that needs the certificate? "www.somedomain.com doesn't have anything to do in this picture." ...www.somedomain.com is the account on my server.. In our case we have many sites on one IP on our server. If I don't have a unique IP address that serves exclusively that site his subdomain is parked on, on MY server why wouldn't www.somedomain.com be a part of this? Seems I need the site to have a unique IP that serves only that site?
    – james-ef
    Oct 16, 2015 at 19:57
  • An account doesn't means anything for HTTP or TLS. What matter is that you have at least one virtualhost (to share an IP with multiple domains) accepting his.subdomain.com. With this, you can server HTTP. Now for TLS, you can now use SNI to serve different certificate for the same IP address. In your case, it means you need the *.subdomain.com certificate (and private key) configure for this same vhost. That might be useful for you: digicert.com/ssl-support/…
    – northox
    Oct 16, 2015 at 22:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .