This question already has an answer here:
https lock and company name in address bar
(1 answer)
Closed 6 years ago.
I do have a website that has an SSL certificate installed when I visit the website I see the look icon like this :
But in some other websites I see the full company description right after the look icon like below :
So my question is : is there a special config that I need to do to my SSL certificate to be able to show my company name after the look icon?
Thanks.
These are two different types of SSL certificates
The first one is either a DV (domain-validated) or an OV (organization-validated). Only the EV (extensive validation) certificate results in the naming of entity being displayed in the browser.
EV certificates are generally more expensive (because of the more detailed validation process) and they requires more time to be issued.
It is worth to mention that, from an encryption point of view, all these 3 tyoes of certificates provide the same level of security.
Related
With Google changing their TLS strictness a few days ago, I just want to share the solution that works for me.
This forum post was the answer. Log in to your Plesk / cPanel and change the SMTP server address to the host name like so:
Images copyrighted to the respective owner(s).
This is a "knowledge capturing" question (i.e. Answer is in the question).
As a complete newbie, I've been skulking through this site for about the past twelve months to find solutions to errors. The following issue has driven me to distraction to such a degree that I decided to join the fun and see if anyone can help.
I have a main site which has an essential SSL certificate. I recently created another site as an add-on domain to the main hosting. However, this means the add-on tries to run as https, causing a security error and blocking most of the html and css document. I'd be very grateful if anyone could offer advice on how to work around this.
The certificates are valid only for the domain specificed in the CN.
However you are not only one with this requirement, so what you can do:
use a wildcard certificate - the wildcard certificates are usually more expensive, but they cover all subdomain on that level (*.domain.com covers www.domain.com, mail.domain.com, ... but not domain.com itself)
use Subject Alternative Name - it is an explicit list of domiains covered by the certificate
I have created a small online market in a sub domain like this:
shopName.mainDomainName.com
I need to install SSL certificate in this shop and possibly other shops in the future.
Can i install once in the main domain and reference that in the sub-domains?
Also, there are many options in SSL certificates that i got confused.
there are Dedicated,Business,and many other plans. from different companies such as comodo,symantech,...
How to choose the right according to my small needs which are simplicity and price.
Thanks in advance for any hint or help.
Based on the comments, you can avail a Wildcard SSL that works for these domain formats
Wildcard SSL
Secures all subdomains but not the base domain itself
Example:
*.mainDomainName.com
Where the * represents any subdomain but not mainDomainName.com
itself.
Subject Alternative Name
Secures all of the specified IP and DNS on the Subject Alternative Name of the Certificate.
Example:
mainDomainName.com
mainDomainName2.com
login.mainDomainName.com
*.mainDomainName.com
As you can see, SAN SSL Certificates offer greater flexibility.
Choose among the given options above that meet your requirements
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
Follow up on the question that I asked here already.
I have Amazon AWS Instance running Windows 2013 server. I have used IIS 8 to generate CSR file. I have used that CSR file in godaddy.com for SSL certificates.
Go daddy gave me following files:
- somerandomhash.crt (2KB)
- gd_bundle-g2-g1.crt (5KB)
In my Sails.js (express.js) I have:
serverOptions : {
key: fs.readFileSync(my.key),
cert: fs.readFileSync(my.cert)
}
I have used http://www.selfsignedcertificate.com/ to create test certificate for my testing domain. That web site provided me with two files, key and cert that work just fine with (ip domain).
Now I need to used proper SSL and I have problems.
How do I update my configuration (serverOptions) to use files provided by godaddy? I do not see a key file anywhere.
IIS should've generated a key along with the CSR. http://www.entrust.net/knowledge-base/technote.cfm?tn=7905 Your SSL provider will not make a key for you, that'd be terribly insecure - you're the only one who's supposed to have a private key.
gd_bundle-g2-g1.crt is a certificate chain file, and should be added to serverOptions like so:
serverOptions : {
key: fs.readFileSync(my.key),
cert: fs.readFileSync(my.cert),
ca: fs.readFileSync(my.ca)
}
After lots of reading this is final solution:
I was getting the following error:
routines:PEM_read_bio:bad end line node.js
No matter what I do I always get that error. Other people who got same error, suggested to add extra enter on header and footer of the request. In my case it did not help. What helped me is Notepad++ and EoL conversion.
I guess you can do it with other editors, but I used Notepad++. Just edit-->EoL Conversion and make sure Windows is selected.
Hopefully it will save time for other people who experience the same problem.
When connecting to the mail server via the email client, we are forced to use SSL. Yet, we only have a self-signed certificate which the IT dept wants us to trust.
What are the real security repercussions?
Assuming the root key doesn't leak, which would break down the whole company CA system, the only issue specific to this use of a self signed certificate is distribution; a certificate authority certificate is normally already on any computer that needs a connection to the server, while this certificate needs to be distributed manually.
If a new computer needs a connection to the server and does not have the certificate, there is no real security if you connect anyway and just accept the certificate. For it to be of any use, it needs to already exist on the computer.
Just as the other two have said, it basically relies on how much you trust your company, which is a factor anyway, so it's likely not a big deal (though they could easily get a free SSL certificate from startcom, so I have no idea why they would insist on a self-signed one).
But as Paul outlined with his example, it also matters if they have you install their own root certificate on your computer; if they don't and instead ask you to click through warning boxes each time, I would suggest speaking up, and emailing a link to this page to your company's IT department.
This is a more complex question than it might appear. The short answer is that if they are following best practices with regard to protecting their self-signed root CA and deploying the root to client machines (incredibly important!) then there is no additional risk beyond that normally incurred with X509 PKI.
The longer answer is, as usual, "it depends what corners they cut". Here's a scenario under which the risk is higher...
Your company does not install the self-signed root directly on
employee laptops. When asked about this oversight they say "that's a
real PITA in a heterogenous computing environment". This (depending on
client and other factors) forces you to choose to click "continue"
through an untrusted dialog each time you launch the client. Big deal
right? It's still encrypted. One day you're in Madrid, enjoying room
service in a five star hotel (as a rising star within the company you
get the poshest assignments) and you open your laptop up to get some
work done...
You always connect to the VPN, but you left your mail client open last
time you put the laptop to sleep and it throws up the same annoying
warning it always shows when you open it. You swiftly click through
the dialog because you've been trained by your IT dept to do so. Sadly,
this time it's a different cert. If you had inspected it directly (you
have a photographic memory and love doing comparisons of base64
encoded public keys) you wouldn't have clicked through, but you were
in a hurry and now the unscrupulous hotel manager running the hotel
capture portal knows your email login and password (p#ssw0rd1).
Unfortunately, you use p#ssw0rd1 on all sorts of other websites, so
you find your reddit, amazon, and even stackoverflow accounts swiftly
compromised. Worse yet, your boss gets an email from "you" with an
obscene rant and notice of resignation. All because you clicked
through that innocuous dialog you've clicked through a thousand times
before.
This (unlikely) scenario is possible when blindly clicking through "untrusted cert" dialogs. Users can (hopefully) be trained to avoid this by telling them not to click through such dialogs and by adding the corporate CA to the trusted roots list of your OS/browser or using a trusted public CA.
It's wrong if you are expected to do anything about it such as click dialog boxes accepting certificates.
If they are doing their job properly they should distribute the certificate internally such that all required network elements already trust it, e.g. browsers, mail user agents, applications, ...
In other words, if you know about it, it's wrong.