Question on SSL Certificate - Help

Here is my scenario

  1. Wordpress Website (www.example.com) - On a hosting server (bluehost/justhost)
  2. Application (app.example.com) - On AWS (Rails API server)

I want to use the SSL certificate to secure my website and app. Where would I have to install the certificate? (justhost or aws or both?)

both

abcdefghijklmnop

1 Like

also to add, you would probably need a wildcard cert to cover both subdomains.

And you’ll either need a wildcard cert like Lampy mentioned, or two certs (one for each domain). The wildcard cert covers ALL subdomains of the 2nd level domain (example.com, www.example.com, app.example.com, images.example.com, et al). Wildcards are better if you control all the subdomains - not so much if cheap/shared domain like mysite.wordpress.com.

2 Likes

For what it’s worth I have become a huge fan of…

…and they apparently have wildcards…

1 Like

Just to clarify that a wild card covers ONLY that level.

so, even with a wildcard, you still need 2 certs likely: example.com (top level) and *.example.com (everything else).

Let’s encrypt is awesome, but their wildcard support is not GA yet, so you are likely best off (if you can manage it) so get individual certs from them for each domain for the time being. That being said, since you’re hosting with dreamhost, you may not be able to install their client which updates the certs since their certs are only valid for 90 days.

There is another “magic” solution through: cloudflare. Use cloudflare to manage your DNS and use their free proxy service and they will provide a free cert for your top level and second layer. they will also provide you with self signed certs to install on your server that don’t expire for 20 years. they manage all certs, etc.

the only downside with cloudflare certs is in the off chance that you want to turn off cloudflare’s proxy (which you shouldn’t need to), you will have self signed certs which will give a warning to users. we use cloudflare across 40 or so properties without issue.

4 Likes

First off lets get the basics down and a bit of the finer points while being as direct as possible, the full standards are documented at https://cabforum.org/information-for-site-owners-and-administrators/

Terminology

A few key terms here are going to be:

  • CA ::= Certificate Authority. This is someone that you the user, the os, and/or the browser attributes as trust worthy to sign your certificate signing request and issue you a certificated. A good CA is one whom has joined the CA/Browser Forum and follows the best practices set forth by them.

  • cab forum ::= CA/Browser Forum. This is the governing body that defines how ssl certificates should be created, the security behind them, and their best practice usage.

  • root ca ::= the top level long lived certificate used to sign a ssl certificate chain. AKA Class 1 certificate

  • intermediate ca ::= The second and/or third level certificate created in the certificate chain which helps manage further certificates down the chain in the case of a breach of the key and/or a sub chain needs to be revoked as a whole without effecting other valid certificates. AKA Class 3 certificate

  • certificate chain ::= A list of certificate starting with the Class 1 then Class 3 and followed with one’s valid ssl certitificate

  • ssl certificate ::= a private + public key pair used to encrypt communications over a tcp communication channel (e.g. https, imaps), this also has the net effect of stating which x509 domain name is vaild plus any extentions that also add on top of what the cert is stating.

  • x509 domain name ::= the subject line written in ldap directory syntax in a ssl certificate which defines who, where, what, and which of the certificate, such as email address, the state, city, country, and zip, of the organization whom owns the domain, which governing body within the origination, and the name of the origination. (e.g. Subject: /C=USA/ST=Texas/L=Dallas/O=Dallas Makerspace/OU=Infrastructure/CN=dallasmakerspace.org which is the subject for dallamakerspace.org)

  • Class 1 Certificate ::= You the user and your email (think one’s ssh pubkey, facebook login, or password)

  • Class 2 Certificate ::= An Organization to which proof of identity is required.

  • Class 3 Certificate ::= Servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority. (think that green lock icon and “verified software” notice in windows UAC)

  • Class 4 Certificate ::= online business transactions between companies (rare in the wild and used more like block chain technology)

  • Class 5 Certificate ::= for private organizations or governmental security (Extended details added to the certificate and generally highest level of communication between government contractors and MILNET) [e.g. Hillary should of had this on her “personal email server”, and trump’s offices too]

How SSL works

  1. Wildcard certs (thanks @lampy):
    These do cover all the above but they also cover vulgarp0rnnamehere.example.com, i-steal-stuff.example.com, breakMySite.example.com, and so forth all at the same time. Not at all secure honestly especially if something between the client and your site intercepts the dns request.

    Either one have a certificitate for your app subdomain and one for your main domain (example.com) with a SAN for the www subdomain. OR have one certificate for your domain (e.g. example.com) and many san records for your official sub domains (e.g. app, www ).

    In the software/security world we call this whitelisting vs blacklisting where a wildcard is a blacklisting model filtered on the domain name and the SAN version is whitelisting.

  2. SAN based Certificates:
    Certificates issuers do not support wildcard as of recent cab forum standard and the ones that do tend to charge out the arse, see point 1.

    These work by listing all valid domain names your laying claim to and would be using publicly starting with the top level domain

  3. SSL Certificates validation: The client (browser, user, etc…) checks for the CN of the x509 domain in the subject line for a cert. This is liken to checking your state issued id to make sure you are whom you claim you are.

  4. Goals and consepts of SSL certificates: SSL certificates are no different than say a deed or physical licence. In that someone with legal power represents the validation of a domain which is signed into a certificate chain via the CA issued Class 1 and Class 3 certificate.

From the perspective a user it works like this:

  • Alice buys a dns domain called imakethings.com, registers it with a domain name service say godaddy and starts a website on tcp port 80 of her new domain

  • Bob wants to visit imakethings.com but doesn’t want his password to be in clear text over the public internet so he would use tcp port 443 on her domain to have the connection validated ssl and encrypted with say RSA encryption
    .

  • Alice goes to a CAB Forum member to use their CA service to validate that she owns imakethings.com they charge her for the service to verify it for the next three years which is about the same as her domain name service at godaddy. lets say she went with letsencrypt because reason.

  • Alice takes the certificate key she made and the certificate public key she got from letsencrypt and installs that on her server which now talks ssl over tcp port 443.

  • Because letsencrypt is already a member of the CAB Forum Browsers like edge, chrome, and firefox already trust letsencypt and has a copy of thier root CA so Bob just needs to visit https://imakethings.com and he’s happy since his browser now knows that imakethings.com is in fact owned by alice, the domain presented the certificate on connection is the same as imakethings.com, and the certificate is currently within the date range of now and when letsencrypt stated its expired (eg the three years from date of signing the certificate)

  • When Bob visits istealthingsnot.imakethings.com he’s safe in known that his browser would complain to him about the domain since that is not what is in the certificate for imakethings.com and will then change the domain name in his browser to visit the real site.

Conclusion

Ok so maybe that was a bit more comprehensive but hopefully one walks away with a better understanding of SSL instead of “get x cert from y person and install on z system to make the green lock icon work” which also in turn should help debug any issues one runs into using SSL certificates.

There’s one other layer in this which is using client certificates issued to say Bob by Alice and that’s basically on the same idea of giving one a key to the door and the licence to use that key for a set time period.

Ultimately the take away here is ssl certificates are your deed to a plot of digital land and proof of ownership. With SAN based certs list all sub divisions on that land (ie subdomains) and wildcards just say communicably everything on this digital is apart of this deed. While one’s web server is the office building on that digital land and the domain name & IP address itself is like the digital street address.

3 Likes