If I go to www.example.com which has an image on the page that links to assets.example.com which is a CNAME for assets.example2.com.
Will I get the green lock even if assets.example2.com does not have a certificate, but assets.example.com does?
Whether your DNS entry uses a CNAME or an A record doesn't matter. What matters is the host name the client is trying to connect to. It must match one of the Subject Alternative Names in the certificate of the server providing that resource (or, failing that, it must match the CN RDN of the cert's Subject DN).
If https://www.example.com embeds an image to https://assets.example.com (providing both are served over HTTPS with valid certificates for each) and if there is no mixed content (no resource loaded over http://, that is no JavaScript, no image, no iframe, ...) then you should get the green/blue bar as appropriate.
If assets.example.com is a CNAME to assets.example2.com and the requests are made to https://assets.example.com, this machine must present a certificate valid for assets.example.com to the client.
In addition, if multiple certificates need to be used at the same time on this IP address (and same port), support for Server Name Indication (SNI) may be required.
Alternatively, having a single certificate that supports all these names, typically via multiple Subject Alternative Name (SANs) entries, or possibly via wildcard names (which are not recommended), may be used.
This is independent of the DNS resolution mechanism (CNAME or A record).
Related
If I go to www.example.com which has an image on the page that links to assets.example.com which is a CNAME for assets.example2.com.
Will I get the green lock even if assets.example2.com does not have a certificate, but assets.example.com does?
Whether your DNS entry uses a CNAME or an A record doesn't matter. What matters is the host name the client is trying to connect to. It must match one of the Subject Alternative Names in the certificate of the server providing that resource (or, failing that, it must match the CN RDN of the cert's Subject DN).
If https://www.example.com embeds an image to https://assets.example.com (providing both are served over HTTPS with valid certificates for each) and if there is no mixed content (no resource loaded over http://, that is no JavaScript, no image, no iframe, ...) then you should get the green/blue bar as appropriate.
If assets.example.com is a CNAME to assets.example2.com and the requests are made to https://assets.example.com, this machine must present a certificate valid for assets.example.com to the client.
In addition, if multiple certificates need to be used at the same time on this IP address (and same port), support for Server Name Indication (SNI) may be required.
Alternatively, having a single certificate that supports all these names, typically via multiple Subject Alternative Name (SANs) entries, or possibly via wildcard names (which are not recommended), may be used.
This is independent of the DNS resolution mechanism (CNAME or A record).
I have something like 100 similar websites in two VPS. I would like to use HAProxy to switch traffic dynamically but at the same time I would like to add an SSL certificate.
I want to use add a variable to call the specific certificate for each website.
For example:
frontend web-https
bind 0.0.0.0:443 ssl crt /etc/ssl/certs/{{domain}}.pem
reqadd X-Forwarded-Proto:\ https
rspadd Strict-Transport-Security:\ max-age=31536000
default_backend website
I'd like also check if the SSL certificate is really available and in case it is not available then switch to HTTP with a redirect.
Is this possibile with HAProxy?
This can be done, but TLS (SSL) does not allow you to do it the way you envision.
First, HAProxy allows you to specify a default certificate and a directory for additonal certificates.
From the documentation for the crt keyword
If a directory name is used instead of a PEM file, then all files found in
that directory will be loaded in alphabetic order unless their name ends with
'.issuer', '.ocsp' or '.sctl' (reserved extensions). This directive may be
specified multiple times in order to load certificates from multiple files or
directories. The certificates will be presented to clients who provide a
valid TLS Server Name Indication field matching one of their CN or alt
subjects. Wildcards are supported, where a wildcard character '*' is used
instead of the first hostname component (eg: *.example.org matches
www.example.org but not www.sub.example.org).
If no SNI is provided by the client or if the SSL library does not support
TLS extensions, or if the client provides an SNI hostname which does not
match any certificate, then the first loaded certificate will be presented.
This means that when loading certificates from a directory, it is highly
recommended to load the default one first as a file or to ensure that it will
always be the first one in the directory.
So, all you need is a directory containing each cert/chain/key in a pem file, and a modification to your configuration like this:
bind 0.0.0.0:443 ssl crt /etc/haproxy/my-default.pem crt /etc/haproxy/my-cert-directory
Note you should also add no-sslv3.
I want to use add a variable to call te specific certificate for each website
As noted in the documentation, if the browser sends Server Name Identification (SNI), then HAProxy will automatically negotiate with the browser using the appropriate certificate.
So configurable cert selection isn't necessary, but more importantly, it isn't possible. SSL/TLS doesn't work that way (anywhere). Until the browser successfully negotiates the secure channel, you don't know what web site the browser will be asking for, because the browser hasn't yet sent the request.
If the browser doesn't speak SNI -- a concern that should be almost entirely irrelevant any more -- or if there is no cert on file that matches the hostname presented in the SNI -- then the default certificate is used for negotiation with the browser.
I'd like also check if the ssl is real available and in case is not available switch to http with a redirect
This is also not possible. Remember, encryption is negotiated first, and only then is the HTTP request sent by the browser.
So, a user will never see your redirect unless they bypass the browser's security warning -- which they must necessarily see, because the hostname in the default certificate won't match the hostname the browser expects to see in the cert.
At this point, there's little point in forcing them back to http, because by bypassing the browser security warning, they have established a connection that is -- simultaneously -- untrusted yet still encrypted. The connection is technically secure but the user has a red × in the address bar because the browser correctly believes that the certificate is invalid (due to the hostname mismatch). But on the user's insistence at bypassing the warning, the browser still uses the invalid certificate to establish the secure channel.
If you really want to redirect even after all of this, you'll need to take a look at the layer 5 fetches. You'll need to verify that the Host header matches the SNI or the default cert, and if your certs are wildcards, you'll need to accommodate that too, but this will still only happen after the user bypasses the security warning.
Imagine if things were so simple that a web server without a valid certificate could hijack traffic by simply redirecting it without the browser requiring the server's certificate being valid (or deliberate action by the user to bypass the warning) and it should become apparent why your original idea not only will not work, but in fact should not work.
Note also that the certificates loaded from the configured directory are all loaded at startup. If you need HAProxy to discover new ones or discard old ones, you need a hot restart of HAProxy (usually sudo service haproxy reload).
A PCI Compliance scanner is balking that the self signed SSL certificate protecting secure access to Plesk Panel contains a name mismatch between the location of the Plesk Panel and the name on the certificate, namely the self-signed cert's name is "Parallels" and the domain to reach Plesk is 'ip address:8443'.
So I figured I would go ahead and get a free SSL certificate to try to fiddle with this error. But when I generated the certificate I used my server domain name as the site name when I generated the certificate. So if I visit 'domain name:8443' all is fine, no ssl warning. But if I visit 'ip address:8443' (which I believe is what the scanner does) I get the certificate name mismatch error, Digicert's ssl checker says that the certificate name should be the ip address.
Can I even generate a certificate whose common name is the ip address? I am tempted to say I should just do what the PCI scanner accepts, but what is really the correct common name to use? Anybody run into this issue before?
You can try a Subject Alternative Name extension for the IP address. Also, you can keep "Parallels" as the Common Name, and add a Subject Alternative Name extension for the DNS name, which should be the preferred match (i.e. higher precedence than Common Name.)
Can I even generate a certificate whose common name is the ip address?
No, you shouldn't. While this may work with some browser, this will fail with clients that are compliant with the HTTPS specification:
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
If you want to use an IP address in a certificate, you must have it in as a Subject Alternative Name (of type IP address, not DNS). You can check this question for details on how to do this.
However, more importantly, it sounds like in your case you don't need to use the IP address at all.
The purpose of certificate name verification is to check that the identity in the certificate matches the identity as requested by the client. (Reverse lookups or other names don't matter.)
The fact that you've already configured your system for your domain name and that it works when using the name means that it's already configured properly. It sounds like your giving your scanning tool the IP address of what you're trying to scan (which isn't what the clients would normally use): make it use your host name instead. That's what the scanning tool should try to compare anyway.
Can I even generate a certificate whose common name is the ip address?
(Thanks Bruno for pointing to right solution) There is enough to set subjectAltName in CSR.
IFAIK there is no such option in Plesk, but here good instruction for openssl http://apetec.com/support/GenerateSAN-CSR.htm
I have a site that has subdomains for each user and a wildcard SSL Cert
https://user1.mysite.com
https://user2.mysite.com
The question is can someone set a cname record such as user1.theirsite.com -> user1.mysite.com and have it still use https?
Will it work if they install a SSL Cert on their server to secure the connection?
Thanks
The best way for this to work is if they arrange with you to have your SSL certificate include their "alias" as a Subject Alternate Name extension in your X.509 certificate.
This is the approach used by some CDNs when they host https sites for clients - they put all of the known site names that are hosted on one server in one large SSL certificate, and then the clients use CNAMEs to point their domain at the right CDN server.
The host name and certificate verification (and in fact, checking that SSL is used at all) are solely the responsibility of the client.
The host name verification will be done by the client, as specified in RFC 2818, based on the host name they request in their URL. Whether the host name DNS resolution is based on a CNAME entry or anything else is irrelevant.
If users are typing https://user1.theirsite.com/ in their browser, the certificate on the target site should be valid for user1.theirsite.com.
If they have their own server for user1.theirsite.com, different to user1.mysite.com, a DNS CNAME entry wouldn't make sense. Assuming the two hosts are effectively distinct, they could have their own valid certificate for user1.theirsite.com and make a redirection to https://user1.theirsite.com/. The redirection would also be visible in the address bar.
If you really wanted to have a CNAME from user1.theirsite.com to user1.mysite.com, they might be able to give you their certificate and private key so that you host it on your site too, using Server Name Indication (assuming same port, and of course same IP address since you're using a CNAME). This would work for clients that support SNI. There would however be a certain risk to them in giving you their private keys (which isn't generally recommended).
The following is set up and working:
DNS entry for a.corp.com -> CNAME b.corp2.com -> A 1.2.3.4
The haproxy at 1.2.3.4 will serve up the cert for a.corp.com and the site loads fine from a webserver backend.
So, on your server you will need user1.theirsite.com cert and it will work.
Is it possible to get one SSL certificate *.mysubdomain.example.com and mysubdomain.example.com, I need because I am using 2 IP on my dedicated server but now I am moving to Azure on azure we can't add two https endpoint. or other solution for azure I need two https endpoint
You can purchase a wildcard SSL certificate that encrypts requests made to *.example.com. This will work for an unlimited number of third-level subdomains. To include the second-level (example.com) and forth-level (subforthlev.subthirdlev.example.com) or higher subdomains, you must find a certificate authority (CA) that allows you to include multiple subject alternate names (SANs) in the wildcard certificate. Each non third-level domain needs to be manually added as a SAN.
Edit: I've used DigiCert's wildcard certificates several times and I have not come across a browser or device that did not have their root certificate installed (see their compatibility list). DigiCert wildcard certs allow you to secure an unlimited number of subdomains regardless of the domain level. Excerpt from first link:
DigiCert WildCard ssl certificates are unique in allowing you to secure ANY subdomain of your domain, including multiple levels of subdomains with one certificate. For example, your WildCard for *.digicert.com com could include server1.sub.mail.digicert.com as a subject alternate name.
If you want your certificate to be valid for both *.mysubdomain.example.com and mysubdomain.example.com, it needs to have a Subject Alternative Name entry for both.
The *.mysubdomain.example.com wildcard expression doesn't cover mysubdomain.example.com.
These rules are defined in RFC 2818 and clarified in RFC 6125:
If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
In practice, that's indeed how most browsers react.
It's however quite likely that a CA issuing a wildcard certificate for *.mysubdomain.example.com will also add a SAN for mysubdomain.example.com. Check with your CA.
You can use multiple SSL certificates and add them all to the same endpoint by automating the process of installing the certificates on the machine and add HTTPS bindings to IIS.
IIS 8 (Windows Server 2012) supports SNI, which enables you to add a "hostheader" to the HTTPS binding.
I'm a Microsoft Technical Evangelist and I have posted a detailed explanation and a sample "plug & play" source-code at:
http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/