How to perform verification processes for EV ssl certification - ssl

I recently purchased EV ssl certificate from comodosslstore.com for my site, which is hosted on GCP and purchased domain from bluehost but now i'm getting some issues to verifying my identity and getting troubles in verification process for my ssl certificate.
So, someone can please tell me what exactly i should do for this verification process, like what should I do as a individual person. Thank you

You will need to follow the rules set by Comodo. The best place is to ask them.
Their job is to provide with reasonable certainty that you are who you say you are.
I have been thru this process many times. They want to see a published phone number in your name that they can verify using public resources. For US companies a Dunn&Bradstreet verification, business license, articles of incorporation, etc.
Comodo will decide which methods that they will use to verify you.
If you are purchasing an SSL certificate as an "individual" you will have difficultly. An EV SSL Certificate means "Extended Validation". Comodo will make a serious effort to verify you and your business and if they cannot, they will not approve your certificate. If you are not a registered business, I wish you luck obtaining one.
If you are not a company, you are a high risk for financial transactions. My advise is to switch and just use a DV SSL Certificate. This is cheaper, requires fewer verification steps and is much easier to obtain. I also recommend to most companies that are not processing financial transactions (credit cards) to use Let's Encrypt. Move your shopping cart to a vendor such as Shopify so that you are not involved in transactions. PCI compliance is difficult and expensive.

7-Stage Authentication For EV SSL Certificates
The EV Enrollment Form
Organization Authentication
Operational Existence
Physical Address
Telephone Verification
Domain Authentication
Final Verification Call
Remember, Whole validation process for EV SSL certificates can take up to a week.
You can get it in deep from this article.

Related

Is my SSL certificate good enough for financial transactions on my shopping cart

I have an online shop and I've just installed a new SSL certificate and it was free. It does seem too good to be true. I'm a very cynical type of person.
I don't know about different types of SSL, but I just need to be able to accept payment data (I'm using a PayPal add-in on Opencart).
I got my certificate from letsencrypt and they don't explain much on there website.
But if you go to my website Gwenllian-retail you will see the certificate. Can I handle financial transactions with that?
If not what type of SSL do I need?
One does not need much money or complicated software to create valid SSL certificates. I could create my own with ease, if I wanted. In fact, I have done. There is no reason to think that LetsEncrypt certificates are somehow of a wrong kind.
The question is whether people will trust those certificates, and that comes back to whether they trust the Certificate Authority (CA) that signed them. If I sign my own certificate and present that to someone as proof of my identity then that other party has no more reason to trust that the data within accurately identify me than if I just told them directly.
LetsEncrypt serves as the CA for SSL certificates it provides. I have never relied on them for a certificate, but according to hosting company DreamHost, LetsEncrypt certificates are trusted by all major browsers. (LetsEncrypt makes the same claim about itself, too.)
Again, all this trust business is mostly about authentication: whether the entity that presents the certificate (your web site) is really the entity that it says it is. It is not about the nature or quality of the encryption with which the session is secured. That comes down to the capabilities of the two endpoints, and is largely independent of the certificate.
Let's Encrypt is a well known service backed up by many big players. So yes, it's OK to use it in on your site. BUT ! SSL certificate is not everything, it's only one of many shields to protect you application.

Are SSL certificates free to make? What high level options are there to obtain one?

If I am confused by this then I'm sure other people must be or at least given it some thought.
What are the options of securing your site with an SSL cert so you can use https?
Obviously you can buy one. I have bought one before on Azure and it gets bound very easily to a web app although its fairly expensive. And you can do the wildcard stuff but this question is not about that.
I have to do it on IIS8. I have done it before but I did it in a hurry so cannot remember if it cost anything. I'm pretty sure I made it myself using some CSR thing (or may be that was just a renewal). But I cannot recall for sure so hoping someone can clarify. I've googled and got links to digicert (https://www.digicert.com/ssl-certificate-renewal-iis-8.htm) but I want another human to verify or to point out the obvious in my understanding.
What are the options of securing your site with an SSL cert so you can use https?
You can generate a self-signed certificate (use case : development)
if you have a private PKI, you can ask the PKI admin to generate a sign a certificate (use case : intranet)
buy a certificate in any well-known provider (digicert, thawte, comodo ; use-case : big company which needs some kind of insurance such as Extended Validation)
take for free a certificate at Letsencrypt (use case : personal website, small company)
In any case there are 3 steps : generating a private key, generating a CSR, and signing a certificate built from this CSR. Remember that if you loose the private key, you're loosing everything and will have to pay again if you paid for the certificate.
This digicert documentation seems OK.
What high level options are there to obtain one?
Second Edit after comments :
The high level options such as Extended Validation gives an insurance to the end-user and a green title in the address bar.
They will cost you more, too, and the benefit vs price should be considered, unless you're running a bank website or a huge online market.
The insurance is for the end-user against fraudulent transactions (details here), it's not about website hacking. This may happen if the certificate issuer delivered by mistake any certificate to the wrong organization, or if the Certificate Authority was hacked itself (some explanations on Quora).
The "256 bits best encrypting" argument that some authorities claim is not honest, since it doesn't change anything. See this question for more explanations about that.

Queries Regarding SSL Certification and Online Payment Gateway

I am developing a event website ( on php and mysql ) which requires online payment for event registration. The payment gateway we have purchased from a bank. The bank asks us to have SSL certificate for our website.. As banks websites usually have Verisign certificate therefore the people with whom we had a conversation told us to have verisign SSL certificate on our event website
When i checked Verisign.com then i found that there are many types of certificates available.
Secure Site Pro with EV
Secure Site with EV
Secure Site Pro
Secure Site
I want to know, is it enough to have the most basic of all.. what difference does it make with different options which are available with verisign. i still believe that the people at the bank have no knowledge of other companies providing SSL certificates. So can i use godaddy or other SSL Certificate providers instead of Verisign.
please help if anyone have worked with payment gateways and SSL Certificates..
You can use any SSL certificate you want. The SSL certificate and payment gateway are independent of each other and one does not directly affect the other. So you can use Godaddy or any other SSL provider you want with your payment gateway.

SSL cert for billing module

I'm writing a billing module for a startup i'm working on. It's my first time buying an SSL cert. I only need a cert for a single domain. Is the standard SSL cert from godaddy ($29.99/yr) all that I need?
I plan to get an authorize.net compatible merchant account and didn't know if they would require the deluxe or premium certs. I'm side strapping this business so I'm trying to do it on the cheap. Thanks
Different certificates sold through the lucrative business of Certificate Authorities carry different price tags, for a few reasons. The most noticeable to clients visiting your web site is how much information the CA decided to "assure", based on how much you paid.
If you could convince your clients that a self-signed certificate has indeed not been compromised, and guarantees no eavesdropping-on-the-internet, then you could get away with $0 certificate cost.
However, users want more than that.
The GoDaddy standard certificate offers domain validation. GoDaddy is recognized by browsers, and will tell your clients that yes, we issued this certificate to https://billing.yourhost.domain, and if you see a website called https://webstore.yourhost.domain using the same certificate, there will be an error in the validation.
Depending on your needs to give client assurance, you may require/desire a certificate for which GoDaddy or another provider will validate a point-of-contact with a business so that when I visit https://billing.washingtonwidgets.com, I can see that this Web site is registered to "Washington Widgets, Ltd.", as opposed to someone who can buy a DNS name for $5 and open up https://paymeinstead.therealwashingtonwidgets.com. This is more "assurance" against spoofers. A spoofer may be able to get a domain validated certificate for a web site which carries a similar name to yours. This extra "assurance" costs more, and several large companies will back the assurance with a warranty, too.
A new type of SSL called EV SSL is marketed to represent one of the highest levels of assurity, and browser vendors are participating in presenting notification to users in a clear manner when a site uses an EV SSL certificate.
An aside from SSL: Now, do you need your own site to be secure? Or can you write a billing module and send a ticket off to a third party ticket billing site such as PayPal, authorize.net, etc. The term you want to look for is payment gateway. Often times these services will charge a small commission, instead of a yearly premium for a similar, but different kind of assurance. They usually offer API's that you can link through your application to create an end-to-end billing experience.
You need to buy a cert from a trusted root authority for your specific domain. I would talk to your hosting provider, as they will need to install the cert etc and may have a mechanism in place for you to go and buy one.
If you're really trying to do it on the cheap, I would def recommend paypal or any other similar service over rolling your own.
Edit: Also, this isn't programming related, maybe something along the lines of "What would a low cost, easy to implement, billing solution be?"

What SSL certificate do I need?

I'm developing software which will be deployed using clickonce (on the website foo.com), and which will then connect to my server using WCF with an encrypted transport
So I need an SSL certificate which will :
Identify my foo.com website has really being my website
Identify the exe I deploy using clickonce as being genuine
Identify my application server has really being my application server.
I also want my SSL certificate to be signed by an authority known to the public (ie, firefox or windows won't ask the user to install the authority's certificate first !)
What SSL certificate would you buy?
I've browsed the Verisign website, the "Secure Site EV" certificate costs 1150€ a year (the "Pro" version seems useful only for compatibility with older browsers)
It sounds like you're looking for two different types of certificates:
1 - SSL Certificate - for authentication of your website/application server.
2 - Code Signing Certificate - for integrity/authentication of the exe you deliver.
Typically those are two different certificates, with two different certificate profiles. At the very least, you need one certificate with two different key usages or extended key usages.
A few thoughts in no specific order:
Check your targeted browsers, they should each have a set of preconfigured root certificates - those are the most widely recognized public certificate sources. I'd probably check both Firefox and IE. Certificate vendors known to me as big names are - Versign, GeoTrust, RSA, Thawte, Entrust. But there's also GoDaddy and many others. Anything that comes in the delivered browser as a Trusted Root Certificate, will allow you to connect to your users without additional greif.
I suggest Googling for both "code signing certificate" and "SSL certificate".
How you configure your site will determine whether or not your website is validated or your authentication server is validated. If the certificate is stored on the apps server, then your user is getting SSL encryption all the way to the server. But many sites put the SSL certificate a little farther forward - like on a firewall, and then stage a collection of apps servers behind it. I don't see a security flaw in that, so long as the networking is carefully configured. To the outside users, both configurations will look the same - they'll get the lock on their browsers and a certificate that tells them that www.foo.com is offering it's credentials.
I'm seeing pretty great deals for SSL Certificates:
- GoDaddy - $12.99
- Register.com - $14.99
But they aren't necessarily code signing certifiates. For example, while GoDaddy's SSL Cert is $12.99, their code signing certs are $199.99! That's part of many certificate vendors business models - lure you in with cheap SSL Certs, and make you pay for code signing. A case could be made that code signing certificates are relatively higher liability. But also... they have to subsidize the cheap SSL certs somehow.
Theoretically, it should be possible to make a certificate that does both code signing and SSL, but I'm not sure you want that. If something should happen, it would be nice to be able to isolate the two functions. Also, I'm pretty sure you'd have to call the certificate vendors and ask if they did this, and if they don't, having them do it will likely jack up the price quite high.
As far as vendor, things to consider:
The technology is pretty much all the same. These days, aim for a minimum of 128 bit keys, I'd probably bump it up to 256, but I'm paranoid.
Beyond browser acceptabiliy, the only reason to pay more would be name recognition. Among the paranoid security wonks, I'd expect RSA, Thawte, Verisign and GeoTrust to have very good reputations. Probably EnTrust, too. This probably only matters if you are dealing with a security focused product. I think your average user will not be so aware.
From a security geek perspective - you're only as safe as the security of your Root CA (Certificate Authority). For the truly paranoid, the thing to do would be to dig into the background material of how the company hosts its root and issuing CAs, how are they physically securited? network security? personnel access control? Also - do they have public CRLs (Certificate Revocation Lists), how do you get a cert revoked? Do they offer OCSP (Online Certificate Status Protocol)? How do they check out certificate requestors to be sure they are giving the right cert to the right person? ... All this stuff really matters if you are offering something that must be highly secure. Things like medical records, financial managment applications, tax information, etc should be highly protected. Most web apps aren't so high risk and probably don't require this degree of scrutiny.
On that last bullet - if you dig into the Verisigns of the world - the very expensive certs - you're likely to see the value. They have a massive infrastructure and take the security of their CAs very seriously. I'm not so sure about the super-cheap hosting services. That said, if your risk is low, US$300 for an SSL Cert doesn't make much sense compared to US$12.99!!
So for web site / application servers you need an SSL certificate. You do not need an EV certificate. I've used ones from QuickSSL for this, as unlike some of the other cheap certificate providers they don't require the installation of an intermediate certificate on the server - that's a no-one for me.
For signing applications that's a different type of certificate altogether (kind of, it's still an X509 certificate, but the one you use for your web site is not one you can use to sign an application). You need an authenticode signing certificate from the likes of Verisign or Globalsign. These are a magnitude more expensive than a plain old SSL certificate and require you to be an incorporated company and produce those documents.