Let's Encrypt and EV certificates for different hosts in the same domain

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












5















I have an e-commerce site host name (example.com) and want to install an Extended Validation TLS certificate for it.



But I use a cookieless static content served from another host name (static.example.com) for images of the website.



To be "Google Shopping friendly" and for secure e-commerce reasons, can I use Let's Encrypt or other domain-validated TLS certificates for static.example.com and EV certificates for example.com?



I have gone through this kind of question online but those were was similar to my situation.










share|improve this question
























  • I don't think the browser cares to displays a green bar for assets (images, css, javascript) so yes, you probably can.

    – Salman A
    Feb 27 at 12:08















5















I have an e-commerce site host name (example.com) and want to install an Extended Validation TLS certificate for it.



But I use a cookieless static content served from another host name (static.example.com) for images of the website.



To be "Google Shopping friendly" and for secure e-commerce reasons, can I use Let's Encrypt or other domain-validated TLS certificates for static.example.com and EV certificates for example.com?



I have gone through this kind of question online but those were was similar to my situation.










share|improve this question
























  • I don't think the browser cares to displays a green bar for assets (images, css, javascript) so yes, you probably can.

    – Salman A
    Feb 27 at 12:08













5












5








5








I have an e-commerce site host name (example.com) and want to install an Extended Validation TLS certificate for it.



But I use a cookieless static content served from another host name (static.example.com) for images of the website.



To be "Google Shopping friendly" and for secure e-commerce reasons, can I use Let's Encrypt or other domain-validated TLS certificates for static.example.com and EV certificates for example.com?



I have gone through this kind of question online but those were was similar to my situation.










share|improve this question
















I have an e-commerce site host name (example.com) and want to install an Extended Validation TLS certificate for it.



But I use a cookieless static content served from another host name (static.example.com) for images of the website.



To be "Google Shopping friendly" and for secure e-commerce reasons, can I use Let's Encrypt or other domain-validated TLS certificates for static.example.com and EV certificates for example.com?



I have gone through this kind of question online but those were was similar to my situation.







tls letsencrypt






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 27 at 11:49









a CVn

6,48812245




6,48812245










asked Feb 27 at 1:43









overeroverer

283




283












  • I don't think the browser cares to displays a green bar for assets (images, css, javascript) so yes, you probably can.

    – Salman A
    Feb 27 at 12:08

















  • I don't think the browser cares to displays a green bar for assets (images, css, javascript) so yes, you probably can.

    – Salman A
    Feb 27 at 12:08
















I don't think the browser cares to displays a green bar for assets (images, css, javascript) so yes, you probably can.

– Salman A
Feb 27 at 12:08





I don't think the browser cares to displays a green bar for assets (images, css, javascript) so yes, you probably can.

– Salman A
Feb 27 at 12:08










4 Answers
4






active

oldest

votes


















11














It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.



Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains. They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.



Apart from that, I recommend to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.






share|improve this answer


















  • 2





    Very good link to Troy Hunt's article, worth the read.

    – WoJ
    Feb 27 at 7:18






  • 2





    Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

    – Lie Ryan
    Feb 27 at 8:32







  • 1





    Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

    – Esa Jokinen
    Feb 27 at 10:34











  • Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

    – overer
    Feb 28 at 8:45






  • 1





    @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

    – Steffen Ullrich
    Feb 28 at 9:06



















3














Yes you can, with some caveats.



Normally, letsencrypt certificate are valid for a single FQDN. So you can create an domain-identified only (DV) certificate for static.example.com and an EV-identified certificate for your root domain.



Note be careful that another consideration applies when using wildcard certificate and some multi domain certificate. Some CAs (including LetsEncrypt) may issue a wildcard that will also be valid for the root domain because the CA may automatically add the root to the SAN (subject alternative name) even if you don't explicitly list your root domain when requesting the certificate (the CA can do this since wildcard certificate verification method requires that you demonstrate control/ownership of the domain's DNS). Check the SAN field of the certificate to be sure that your certificate are covering exactly what you expected and no more.



A couple security notes though, be careful of server settings that may apply to all subdomains, like certain Cookies and HSTS config.






share|improve this answer




















  • 2





    Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

    – dave_thompson_085
    Feb 27 at 4:17











  • @dave_thompson_085: I've updated the answer to be more precise with the wordings.

    – Lie Ryan
    Feb 27 at 10:49


















1














There are three options for this situation:



  1. Go with wildcard ssl certificate to secure your root and its sub domains because it remains easy for you because through option you will have to manage only one certificate for both root and its sub domain that helps to save your time & money.

  2. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then go for Symantec EV SSL which now gives facility to secure multi domain with it. (Usually remains high in the price).

  3. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then other affordable option is EV Multi Domain SSL because it helps you to get ev ssl for your all multiple domains (which you will include in SAN category). Means your both both root as well as sub domain will be secured with EV SSL.





share|improve this answer

























  • Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

    – Luc
    Feb 27 at 10:17











  • Thank you for keeping my attention to that.

    – Dana
    Feb 27 at 11:06


















1














It has been established that there's no technical limitations:



  • You can buy certificates for the same domain from different sources.


  • DV and EV certificates can be mixed on different subdomains or even on different instances of the very same hostname, like e.g. Twitter does.


  • Wildcard and multidomain certificates can co-exists on the same domain in any combination.


In his answer Lie Ryan explains some caveats I would like to extend a little and then provide some solutions that don't directly answer the question, but may be helpful in this situation. This is also what truly makes this a security question rather than a general question about server configuration.



It's not only you who could get a DV certificate under your domain, whether it already has an EV certificate or not, but anyone who has access to the document root on your subdomain can get a DV certificate for it. It's very common that using some third party service requires an additional A / AAAA record to your DNS zone.




Administrative control though CAA records



In this situation Certification Authority Authorization (CAA) Resource Records specified in RFC 6844 may become useful. It was mandated in Sep 2017 by CA/Browser Forum, so now it's finally useful. If you would like e.g. only Symantec to issue certificates for your domain, you'd add a DNS record:



example.com. IN CAA 128 issue "symantec.com"


Now, you need also to have Let's Encrypt for your static.example.com and for that subdomain alone i.e. you don't want thirdparty.example.com to be able to get one, too. The CAA is inherited from the parent domain, but a new CAA record will override it. Finally, issue ";" states no CA should issue a certificate.



static.example.com. IN CAA 128 issue "letsencrypt.org"
thirdparty.example.com. IN CAA 128 issue ";"



Technical control through HTTP Public Key Pinning (HPKP)



This is technically stronger than the CAA approach, paranoia level up, but is not an alternative to it. There's this Public-Key-Pins response header that could list hashes for your certificates.



The server having your EV certificate can introduce your static.example.com DV certificate's public key with its own, making both trusted by the browsers and anything else untrusted. But this can also be a lot more dangerous:




HPKP has the potential to lock out users for a long time if used
incorrectly! The use of backup certificates and/or pinning the CA
certificate is recommend.







share|improve this answer
























    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "162"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204359%2flets-encrypt-and-ev-certificates-for-different-hosts-in-the-same-domain%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    11














    It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.



    Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains. They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.



    Apart from that, I recommend to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.






    share|improve this answer


















    • 2





      Very good link to Troy Hunt's article, worth the read.

      – WoJ
      Feb 27 at 7:18






    • 2





      Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

      – Lie Ryan
      Feb 27 at 8:32







    • 1





      Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

      – Esa Jokinen
      Feb 27 at 10:34











    • Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

      – overer
      Feb 28 at 8:45






    • 1





      @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

      – Steffen Ullrich
      Feb 28 at 9:06
















    11














    It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.



    Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains. They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.



    Apart from that, I recommend to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.






    share|improve this answer


















    • 2





      Very good link to Troy Hunt's article, worth the read.

      – WoJ
      Feb 27 at 7:18






    • 2





      Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

      – Lie Ryan
      Feb 27 at 8:32







    • 1





      Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

      – Esa Jokinen
      Feb 27 at 10:34











    • Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

      – overer
      Feb 28 at 8:45






    • 1





      @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

      – Steffen Ullrich
      Feb 28 at 9:06














    11












    11








    11







    It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.



    Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains. They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.



    Apart from that, I recommend to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.






    share|improve this answer













    It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.



    Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains. They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.



    Apart from that, I recommend to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Feb 27 at 4:31









    Steffen UllrichSteffen Ullrich

    119k15209276




    119k15209276







    • 2





      Very good link to Troy Hunt's article, worth the read.

      – WoJ
      Feb 27 at 7:18






    • 2





      Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

      – Lie Ryan
      Feb 27 at 8:32







    • 1





      Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

      – Esa Jokinen
      Feb 27 at 10:34











    • Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

      – overer
      Feb 28 at 8:45






    • 1





      @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

      – Steffen Ullrich
      Feb 28 at 9:06













    • 2





      Very good link to Troy Hunt's article, worth the read.

      – WoJ
      Feb 27 at 7:18






    • 2





      Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

      – Lie Ryan
      Feb 27 at 8:32







    • 1





      Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

      – Esa Jokinen
      Feb 27 at 10:34











    • Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

      – overer
      Feb 28 at 8:45






    • 1





      @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

      – Steffen Ullrich
      Feb 28 at 9:06








    2




    2





    Very good link to Troy Hunt's article, worth the read.

    – WoJ
    Feb 27 at 7:18





    Very good link to Troy Hunt's article, worth the read.

    – WoJ
    Feb 27 at 7:18




    2




    2





    Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

    – Lie Ryan
    Feb 27 at 8:32






    Overlapping certificates can actually be a problem for this particular case. If OP passess the key for static.example.com to a CDN but maintain example.com in their own control, then the CDN operator and an attacker who breached CDN operator's security will be able to snoop/impersonate example.com. Note that to actually prevent breaches of trust like this completely, you'll also need to use subresource integrity to prevent your CDN from modifying and injecting scripts into your pages.

    – Lie Ryan
    Feb 27 at 8:32





    1




    1





    Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

    – Esa Jokinen
    Feb 27 at 10:34





    Troy Hunt's extended blog post on EV certificates. A bit less of examples would have been more than enough. Still, it's so entertaining that it's hard to stop reading it.

    – Esa Jokinen
    Feb 27 at 10:34













    Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

    – overer
    Feb 28 at 8:45





    Troy Hunt's article is interesting but he talks "only" about the green bar, it's like EV is only a gadget, and there is not diferrence between EV and DV.

    – overer
    Feb 28 at 8:45




    1




    1





    @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

    – Steffen Ullrich
    Feb 28 at 9:06






    @overer: The only relevant difference between EV and DV from the perspective of the user is how the trust to the site is displayed (i.e. green bar). Also the article does not only talk about this but also about the inconsistent use of EV vs DV certificates for the same domain by Twitter (depending on the clients location) and that lots of major sites obviously question the value of EV but not using it.

    – Steffen Ullrich
    Feb 28 at 9:06














    3














    Yes you can, with some caveats.



    Normally, letsencrypt certificate are valid for a single FQDN. So you can create an domain-identified only (DV) certificate for static.example.com and an EV-identified certificate for your root domain.



    Note be careful that another consideration applies when using wildcard certificate and some multi domain certificate. Some CAs (including LetsEncrypt) may issue a wildcard that will also be valid for the root domain because the CA may automatically add the root to the SAN (subject alternative name) even if you don't explicitly list your root domain when requesting the certificate (the CA can do this since wildcard certificate verification method requires that you demonstrate control/ownership of the domain's DNS). Check the SAN field of the certificate to be sure that your certificate are covering exactly what you expected and no more.



    A couple security notes though, be careful of server settings that may apply to all subdomains, like certain Cookies and HSTS config.






    share|improve this answer




















    • 2





      Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

      – dave_thompson_085
      Feb 27 at 4:17











    • @dave_thompson_085: I've updated the answer to be more precise with the wordings.

      – Lie Ryan
      Feb 27 at 10:49















    3














    Yes you can, with some caveats.



    Normally, letsencrypt certificate are valid for a single FQDN. So you can create an domain-identified only (DV) certificate for static.example.com and an EV-identified certificate for your root domain.



    Note be careful that another consideration applies when using wildcard certificate and some multi domain certificate. Some CAs (including LetsEncrypt) may issue a wildcard that will also be valid for the root domain because the CA may automatically add the root to the SAN (subject alternative name) even if you don't explicitly list your root domain when requesting the certificate (the CA can do this since wildcard certificate verification method requires that you demonstrate control/ownership of the domain's DNS). Check the SAN field of the certificate to be sure that your certificate are covering exactly what you expected and no more.



    A couple security notes though, be careful of server settings that may apply to all subdomains, like certain Cookies and HSTS config.






    share|improve this answer




















    • 2





      Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

      – dave_thompson_085
      Feb 27 at 4:17











    • @dave_thompson_085: I've updated the answer to be more precise with the wordings.

      – Lie Ryan
      Feb 27 at 10:49













    3












    3








    3







    Yes you can, with some caveats.



    Normally, letsencrypt certificate are valid for a single FQDN. So you can create an domain-identified only (DV) certificate for static.example.com and an EV-identified certificate for your root domain.



    Note be careful that another consideration applies when using wildcard certificate and some multi domain certificate. Some CAs (including LetsEncrypt) may issue a wildcard that will also be valid for the root domain because the CA may automatically add the root to the SAN (subject alternative name) even if you don't explicitly list your root domain when requesting the certificate (the CA can do this since wildcard certificate verification method requires that you demonstrate control/ownership of the domain's DNS). Check the SAN field of the certificate to be sure that your certificate are covering exactly what you expected and no more.



    A couple security notes though, be careful of server settings that may apply to all subdomains, like certain Cookies and HSTS config.






    share|improve this answer















    Yes you can, with some caveats.



    Normally, letsencrypt certificate are valid for a single FQDN. So you can create an domain-identified only (DV) certificate for static.example.com and an EV-identified certificate for your root domain.



    Note be careful that another consideration applies when using wildcard certificate and some multi domain certificate. Some CAs (including LetsEncrypt) may issue a wildcard that will also be valid for the root domain because the CA may automatically add the root to the SAN (subject alternative name) even if you don't explicitly list your root domain when requesting the certificate (the CA can do this since wildcard certificate verification method requires that you demonstrate control/ownership of the domain's DNS). Check the SAN field of the certificate to be sure that your certificate are covering exactly what you expected and no more.



    A couple security notes though, be careful of server settings that may apply to all subdomains, like certain Cookies and HSTS config.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 27 at 10:47

























    answered Feb 27 at 2:39









    Lie RyanLie Ryan

    23.5k35077




    23.5k35077







    • 2





      Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

      – dave_thompson_085
      Feb 27 at 4:17











    • @dave_thompson_085: I've updated the answer to be more precise with the wordings.

      – Lie Ryan
      Feb 27 at 10:49












    • 2





      Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

      – dave_thompson_085
      Feb 27 at 4:17











    • @dave_thompson_085: I've updated the answer to be more precise with the wordings.

      – Lie Ryan
      Feb 27 at 10:49







    2




    2





    Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

    – dave_thompson_085
    Feb 27 at 4:17





    Multidomain and wildcard are quite different things; LE does the first semiautomatically but not the second. Even if an LE cert does mistakenly include the bare domain, it's perfectly valid to not use that cert for that domain, as long as you can configure your webserver(s?) to do so.

    – dave_thompson_085
    Feb 27 at 4:17













    @dave_thompson_085: I've updated the answer to be more precise with the wordings.

    – Lie Ryan
    Feb 27 at 10:49





    @dave_thompson_085: I've updated the answer to be more precise with the wordings.

    – Lie Ryan
    Feb 27 at 10:49











    1














    There are three options for this situation:



    1. Go with wildcard ssl certificate to secure your root and its sub domains because it remains easy for you because through option you will have to manage only one certificate for both root and its sub domain that helps to save your time & money.

    2. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then go for Symantec EV SSL which now gives facility to secure multi domain with it. (Usually remains high in the price).

    3. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then other affordable option is EV Multi Domain SSL because it helps you to get ev ssl for your all multiple domains (which you will include in SAN category). Means your both both root as well as sub domain will be secured with EV SSL.





    share|improve this answer

























    • Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

      – Luc
      Feb 27 at 10:17











    • Thank you for keeping my attention to that.

      – Dana
      Feb 27 at 11:06















    1














    There are three options for this situation:



    1. Go with wildcard ssl certificate to secure your root and its sub domains because it remains easy for you because through option you will have to manage only one certificate for both root and its sub domain that helps to save your time & money.

    2. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then go for Symantec EV SSL which now gives facility to secure multi domain with it. (Usually remains high in the price).

    3. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then other affordable option is EV Multi Domain SSL because it helps you to get ev ssl for your all multiple domains (which you will include in SAN category). Means your both both root as well as sub domain will be secured with EV SSL.





    share|improve this answer

























    • Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

      – Luc
      Feb 27 at 10:17











    • Thank you for keeping my attention to that.

      – Dana
      Feb 27 at 11:06













    1












    1








    1







    There are three options for this situation:



    1. Go with wildcard ssl certificate to secure your root and its sub domains because it remains easy for you because through option you will have to manage only one certificate for both root and its sub domain that helps to save your time & money.

    2. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then go for Symantec EV SSL which now gives facility to secure multi domain with it. (Usually remains high in the price).

    3. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then other affordable option is EV Multi Domain SSL because it helps you to get ev ssl for your all multiple domains (which you will include in SAN category). Means your both both root as well as sub domain will be secured with EV SSL.





    share|improve this answer















    There are three options for this situation:



    1. Go with wildcard ssl certificate to secure your root and its sub domains because it remains easy for you because through option you will have to manage only one certificate for both root and its sub domain that helps to save your time & money.

    2. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then go for Symantec EV SSL which now gives facility to secure multi domain with it. (Usually remains high in the price).

    3. If want EV SSL for root domain example.com and also want to secure sub domain static.example.com then other affordable option is EV Multi Domain SSL because it helps you to get ev ssl for your all multiple domains (which you will include in SAN category). Means your both both root as well as sub domain will be secured with EV SSL.






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 27 at 11:05

























    answered Feb 27 at 9:20









    DanaDana

    213




    213












    • Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

      – Luc
      Feb 27 at 10:17











    • Thank you for keeping my attention to that.

      – Dana
      Feb 27 at 11:06

















    • Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

      – Luc
      Feb 27 at 10:17











    • Thank you for keeping my attention to that.

      – Dana
      Feb 27 at 11:06
















    Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

    – Luc
    Feb 27 at 10:17





    Your answer is a little short: you mention a few options as bullet points, but not what pros and cons are for each option. The answer also contains some typos. It's a good start for a useful answer, but to get more upvotes, you might want to expand the answer.

    – Luc
    Feb 27 at 10:17













    Thank you for keeping my attention to that.

    – Dana
    Feb 27 at 11:06





    Thank you for keeping my attention to that.

    – Dana
    Feb 27 at 11:06











    1














    It has been established that there's no technical limitations:



    • You can buy certificates for the same domain from different sources.


    • DV and EV certificates can be mixed on different subdomains or even on different instances of the very same hostname, like e.g. Twitter does.


    • Wildcard and multidomain certificates can co-exists on the same domain in any combination.


    In his answer Lie Ryan explains some caveats I would like to extend a little and then provide some solutions that don't directly answer the question, but may be helpful in this situation. This is also what truly makes this a security question rather than a general question about server configuration.



    It's not only you who could get a DV certificate under your domain, whether it already has an EV certificate or not, but anyone who has access to the document root on your subdomain can get a DV certificate for it. It's very common that using some third party service requires an additional A / AAAA record to your DNS zone.




    Administrative control though CAA records



    In this situation Certification Authority Authorization (CAA) Resource Records specified in RFC 6844 may become useful. It was mandated in Sep 2017 by CA/Browser Forum, so now it's finally useful. If you would like e.g. only Symantec to issue certificates for your domain, you'd add a DNS record:



    example.com. IN CAA 128 issue "symantec.com"


    Now, you need also to have Let's Encrypt for your static.example.com and for that subdomain alone i.e. you don't want thirdparty.example.com to be able to get one, too. The CAA is inherited from the parent domain, but a new CAA record will override it. Finally, issue ";" states no CA should issue a certificate.



    static.example.com. IN CAA 128 issue "letsencrypt.org"
    thirdparty.example.com. IN CAA 128 issue ";"



    Technical control through HTTP Public Key Pinning (HPKP)



    This is technically stronger than the CAA approach, paranoia level up, but is not an alternative to it. There's this Public-Key-Pins response header that could list hashes for your certificates.



    The server having your EV certificate can introduce your static.example.com DV certificate's public key with its own, making both trusted by the browsers and anything else untrusted. But this can also be a lot more dangerous:




    HPKP has the potential to lock out users for a long time if used
    incorrectly! The use of backup certificates and/or pinning the CA
    certificate is recommend.







    share|improve this answer





























      1














      It has been established that there's no technical limitations:



      • You can buy certificates for the same domain from different sources.


      • DV and EV certificates can be mixed on different subdomains or even on different instances of the very same hostname, like e.g. Twitter does.


      • Wildcard and multidomain certificates can co-exists on the same domain in any combination.


      In his answer Lie Ryan explains some caveats I would like to extend a little and then provide some solutions that don't directly answer the question, but may be helpful in this situation. This is also what truly makes this a security question rather than a general question about server configuration.



      It's not only you who could get a DV certificate under your domain, whether it already has an EV certificate or not, but anyone who has access to the document root on your subdomain can get a DV certificate for it. It's very common that using some third party service requires an additional A / AAAA record to your DNS zone.




      Administrative control though CAA records



      In this situation Certification Authority Authorization (CAA) Resource Records specified in RFC 6844 may become useful. It was mandated in Sep 2017 by CA/Browser Forum, so now it's finally useful. If you would like e.g. only Symantec to issue certificates for your domain, you'd add a DNS record:



      example.com. IN CAA 128 issue "symantec.com"


      Now, you need also to have Let's Encrypt for your static.example.com and for that subdomain alone i.e. you don't want thirdparty.example.com to be able to get one, too. The CAA is inherited from the parent domain, but a new CAA record will override it. Finally, issue ";" states no CA should issue a certificate.



      static.example.com. IN CAA 128 issue "letsencrypt.org"
      thirdparty.example.com. IN CAA 128 issue ";"



      Technical control through HTTP Public Key Pinning (HPKP)



      This is technically stronger than the CAA approach, paranoia level up, but is not an alternative to it. There's this Public-Key-Pins response header that could list hashes for your certificates.



      The server having your EV certificate can introduce your static.example.com DV certificate's public key with its own, making both trusted by the browsers and anything else untrusted. But this can also be a lot more dangerous:




      HPKP has the potential to lock out users for a long time if used
      incorrectly! The use of backup certificates and/or pinning the CA
      certificate is recommend.







      share|improve this answer



























        1












        1








        1







        It has been established that there's no technical limitations:



        • You can buy certificates for the same domain from different sources.


        • DV and EV certificates can be mixed on different subdomains or even on different instances of the very same hostname, like e.g. Twitter does.


        • Wildcard and multidomain certificates can co-exists on the same domain in any combination.


        In his answer Lie Ryan explains some caveats I would like to extend a little and then provide some solutions that don't directly answer the question, but may be helpful in this situation. This is also what truly makes this a security question rather than a general question about server configuration.



        It's not only you who could get a DV certificate under your domain, whether it already has an EV certificate or not, but anyone who has access to the document root on your subdomain can get a DV certificate for it. It's very common that using some third party service requires an additional A / AAAA record to your DNS zone.




        Administrative control though CAA records



        In this situation Certification Authority Authorization (CAA) Resource Records specified in RFC 6844 may become useful. It was mandated in Sep 2017 by CA/Browser Forum, so now it's finally useful. If you would like e.g. only Symantec to issue certificates for your domain, you'd add a DNS record:



        example.com. IN CAA 128 issue "symantec.com"


        Now, you need also to have Let's Encrypt for your static.example.com and for that subdomain alone i.e. you don't want thirdparty.example.com to be able to get one, too. The CAA is inherited from the parent domain, but a new CAA record will override it. Finally, issue ";" states no CA should issue a certificate.



        static.example.com. IN CAA 128 issue "letsencrypt.org"
        thirdparty.example.com. IN CAA 128 issue ";"



        Technical control through HTTP Public Key Pinning (HPKP)



        This is technically stronger than the CAA approach, paranoia level up, but is not an alternative to it. There's this Public-Key-Pins response header that could list hashes for your certificates.



        The server having your EV certificate can introduce your static.example.com DV certificate's public key with its own, making both trusted by the browsers and anything else untrusted. But this can also be a lot more dangerous:




        HPKP has the potential to lock out users for a long time if used
        incorrectly! The use of backup certificates and/or pinning the CA
        certificate is recommend.







        share|improve this answer















        It has been established that there's no technical limitations:



        • You can buy certificates for the same domain from different sources.


        • DV and EV certificates can be mixed on different subdomains or even on different instances of the very same hostname, like e.g. Twitter does.


        • Wildcard and multidomain certificates can co-exists on the same domain in any combination.


        In his answer Lie Ryan explains some caveats I would like to extend a little and then provide some solutions that don't directly answer the question, but may be helpful in this situation. This is also what truly makes this a security question rather than a general question about server configuration.



        It's not only you who could get a DV certificate under your domain, whether it already has an EV certificate or not, but anyone who has access to the document root on your subdomain can get a DV certificate for it. It's very common that using some third party service requires an additional A / AAAA record to your DNS zone.




        Administrative control though CAA records



        In this situation Certification Authority Authorization (CAA) Resource Records specified in RFC 6844 may become useful. It was mandated in Sep 2017 by CA/Browser Forum, so now it's finally useful. If you would like e.g. only Symantec to issue certificates for your domain, you'd add a DNS record:



        example.com. IN CAA 128 issue "symantec.com"


        Now, you need also to have Let's Encrypt for your static.example.com and for that subdomain alone i.e. you don't want thirdparty.example.com to be able to get one, too. The CAA is inherited from the parent domain, but a new CAA record will override it. Finally, issue ";" states no CA should issue a certificate.



        static.example.com. IN CAA 128 issue "letsencrypt.org"
        thirdparty.example.com. IN CAA 128 issue ";"



        Technical control through HTTP Public Key Pinning (HPKP)



        This is technically stronger than the CAA approach, paranoia level up, but is not an alternative to it. There's this Public-Key-Pins response header that could list hashes for your certificates.



        The server having your EV certificate can introduce your static.example.com DV certificate's public key with its own, making both trusted by the browsers and anything else untrusted. But this can also be a lot more dangerous:




        HPKP has the potential to lock out users for a long time if used
        incorrectly! The use of backup certificates and/or pinning the CA
        certificate is recommend.








        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 27 at 16:08

























        answered Feb 27 at 16:03









        Esa JokinenEsa Jokinen

        3,2941119




        3,2941119



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Information Security Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f204359%2flets-encrypt-and-ev-certificates-for-different-hosts-in-the-same-domain%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?