Can I purchase a single SSL certificate for domain A and sign all of my other domains with the domain A as reference.
Will it work ?
You certainly can install those certificates. However just as with self-signed certificates the main problem is that they cannot be validated by browsers due to a broken verification chain.
In short: it won't work as you desire.
No, you can't. The certificate for SSL is issued with specific allowed usage (which is encoded in the certificate). This does not includes signing other certificates.
Consequently though you technically will be able to sign certificates for other domains using the key of certificate A, such signed certificates will not be validated right and will not work.
I think you're looking for wildcard certificates. Issuing a cert for *.mydomain.com would be valid for sub1.mydomain.com, sub2.mydomain.com, etc.
If you're looking to get a cert for mydomain.com and use that to generate a cert for otherdomain.com, that won't work.
FYI, wildcard certs are more considerably more expensive from what I remember.
EDIT:
Rereading your question, you want to do second option, and no, you can't do that. You'll wind up with an invalid cert and most browsers put up giant warning signs that the cert isn't from a trusted source. It will reference your cert for domain A as a trusted signer, which it is NOT, even though it WAS issued by a trusted signer further up the chain. If what you wanted to do was possible, the entire trusted signer/TLS infrastructure would be useless. (The utility of basic TLS as a verification that you're dealing with whom you think your dealing is debatable since it's trivial/inexpensive to get a cert. Hence the existence of Extended Validation Certificates.)
You can not sign further certificates from your certificate. Otherwise you could sign somethign like www.paypal.com under your own legitimate SSL certificate - This was demonstrated as possible via a MITM attack at a blackhat conference but this has since been rendered no possible.
However you can get Multi-Domain certificates. These certificates allow you to include additional domains in the SAN field (Subject Alternative Name). So the certificate is generated for a single domain and the additional domains are added during the enrollment process with your SSL provider. You will need to verify ownership of each domain you request.
These certificates allow you to host multiple FQDN on a single IP with one SSL certificate.
In addition there are also wildcard certificates but these only let you secure *.domain.com with a single certificate.
Related
For firewall purposes, trying to identify the cert revocation URL's for the major root CA's. Are these documented somewhere?
In addition to Crypt32's answer you should be able to get a CRL from a certificate itself. For instance if you look at the certificate for https://www.google.com (using a browser) you can see a CRL distribution point of http://crl.pki.goog/GTS1O1.crl
The two certificates above it in the chain also have CRLs.
I am a novice in SSL working on a Spring web application running directly off of an Apache Tomcat server. It is currently configured to be able to use LDAP (non-SSL) for authentication (this was set up by a previous developer). It also is running over http (also not SSL).
I want to be able to use both LDAPS and HTTPS.
My question is will I be able to use the same certificate to enable SSL for both LDAPS usage and HTTPS usage?
You can use the same certificate if:
you use the same server name in both cases or
if you have a certificate covering both names, with both names listed in the certificate, or
if they have some common domain suffix and you have a relevant wildcard certificate
Remember that certificates are used to prove the identity of some remote endpoint, and it is typically based on the hostname of the endpoint, as shown in some URLs, either for HTTPS or LDAPS.
RFC 6125 describes how identity is checked with certificates. Section 6 for the generic idea, and then appendix B.2 for HTTPS case and B.3 for LDAPS. They both use the name.
Having a HTTPS is good for websites, if there is any confidential data is handled.
But now-a-days even, Content management sites too having the Https.
Is there any reason behind it.
Any kind of advantage (like security or related to search optimization etc.) will we get, if a normal (static content/dynamic content) website is having the Https.
Could some one share some input in this.
Google has taken a strict stance to ensure that it protects the privacy of their consumers. Security, they say, has always been “a top priority” for them.
Here's What Is the Overall HTTPS SEO Impact
Encrypting HTTP over SSL not only secures traffic, but it tells your browser that the site you're visiting has been verified by a Certificate Authority.
You browser has a store containing the public keys of all the Certificate Authorities it trusts. When you visit a HTTPS site, the SSL certificate states which Certificated Authority issued their cert.
Your browser uses the public key of that Certificate Authority to try and decrypt the certificate. If this works - the site can be trusted.
I could find any quick answer on google. Most probably the answer lies somewhere in RFC docs on http or https however I just couldn't (too time consuming ) get those information.
So here is the question:
Is the content of a webpage served through HTTP signed digitally by the server ? Same question for HTTPS.
If yes, how does it work correctly when using a proxy ? In my opinion the proxy could tamper the data, sign the tampered data with it's own private key, and claim that the corresponding proxy's public key is actually the genuine public key of the original server ? I am assuming that the client can't check the original server's public key, because there is a proxy which could lie.
I am sorry if this is a dump question and easy searchable on the internet, but every answer I found posed some doubts to me.
Thanks for your help :)
Content sent via HTTPS is encrypted, clients verify the authenticity of the host certificates with whom they are communicating. The server uses a TLS/SSL key/certificate which is signed by certificate authorities (CA) The CAs make sure that they only sign the certificates of the rightful owners of a domain. The certificates of the CAs them-self are installed in you browser/OS. By using these pre-installed certificates, the browser can check if the key used by the remote server is signed by a trusted CA.
A man-in-the-middle does not have the original key, nor another key signed by a CA for the domain in question. Therefore, a man-in-the-middle cannot modify the content without breaking HTTPS.
On the other hand, if you want to use a proxy to cache requests, the proxy can terminate the HTTPS connections. This means the proxy has its own connection to the server and verifies the certificates. In order to secure the connection to the client, the proxy acts as a CA and uses a HTTPS connection with self-signed certificates. To avoid that your browser complains about an insecure connection, you need to install the proxies own CA certificate.
HTTP content is not signed and can be tampered with.
Edit 2018-06-15:
I wasn't really precise with the term "signed" here. The server does not actually sign the content it sends. This means if you store the responses from the server, you cannot prove that they came from that server, in other words: standard TLS dose not provide non-repudiation. However, the authenticity of the server is established during the handshake. The client encrypts a master-key with the servers public key. Only servers in possession of the private key can decrypt the master-key and derive session keys from them.
CAs, on the other hand, actually sign the certificates. A CA cannot validly deny that it signed for the authenticity of a server certificate.
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot