I have set up the following self-signed certificates on Mac OS X 10.6.8 and made them trusted in Keychain Access:
*.la.com *.la.mx *.la.es
*.la.ca *.la.com.ar *.la.co.nz
*.la.us *.la.co.uk
However, for a reason that I can not understand the *.la.us certificate can not be trusted even though I follow the exact same process in creating it and trusting it. In fact, if I do not trust and then trust each of the certificates they work and I get a green pad lock in Chrome 43.0.2357.132 (64-bit) "except" for the *.la.us.
For *.la.us I get:
Your connection is not private
Attackers might be trying to steal your information from www.la.us (for example, passwords, messages or credit cards). NET_ERR_CERT_COMMON_NAME_INVALID
If I click on Advanced I see:
This server could not prove that it is www.la.us; its security certificate is from *.la.us. This may be caused by a misconfiguration or an attacker intercepting your connection.
If I proceed and click on the red padlock I see:
Server's certificate does not match the URL.
How is it the server's certificate does not match the URL when it clearly tells me it's www.la.us and the certificate is for *.la.us?
Is there something special about the domain la.us? I have re-created the cert several times, re-entered the MAMP Apache virtual conf several times, and tried Keychain Access again and again (removing the cert in between). Any thoughts anyone?
There are special rules for domains inside the .us name space and it looks like Chrome is enforcing these. From the Wikipedia entry for .us:
A two-letter second-level domain is formally reserved for each U.S. state, federal territory, and the District of Columbia....
These rules also reflected in the public suffix list where you find special entries for la.us and also various subdomains like k12.la.us.
These special rules suggest that there is no single owner of the *.la.us namespace and thus you should not be able to get a wildcard certificate for *.la.us. This is similar to the uk and co.uk namespaces where you can not get certificates for *.co.uk but only for *.la.co.uk. Note that not all of the rules in the public suffix list are used by all browsers to check the subject of the certificates.
Related
I want my site to be secure using HTTPS protocols. I managed to make a self-signed key to be trustedCertEntry as I made my own CA certificate, with different CN, which I used to sign my own private certificate.
It works smooth testing it with openssl with something like:
openssl s_client -connect www.mydomain.com:80 -tls1 -state
Thus, browser doesn't report a certificate self-signed error, as it sees a different CA.
But I get a SEC_ERROR_UNKNOWN_ISSUER error. Still it seems logical to me as nobody knows me as a CA. It is supposed to work if user adds exception for me.
I thought this trick was acceptable and it was like many https compliant sites were working, as you may visit a unknown site and you want to encrypt communications from 3rd party watchers but trust that page.
After trying to get a clear response for it, beyond coding that I will find resources, my question is:
If I want to have a site, for which the users don't have to add an exception in the first visit, do I have to get a certificate from a "world-known" CA? Or am I missing a solution for self-signing my certificate with my own CA certificate?
Technically speaking, the answer is: Yes, you will have to get a certificate from a CA that is trusted by your users' browsers via a chain of intermediary CA's that ends at an inherently trusted root CA. The accepted answer to this question explains how it works: SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
Having said that, if your "only" concern is to provide encrypted connections, you might be able to leverage the Let's Encrypt CA, which provides free certificates for that purpose. Those certificates will be only domain-validated, which provides a weaker kind of assurance of identity than, for example, an Extended Validation Certificate.
Depending on the browser used, there will be minimal difference in user experience between DV and EV certificates. For Safari, the user will see a grey padlock in the address bar for the lower assurance DV-backed sites, like this:
and a green padlock when higher identity assurance is provided, like this:
Whether the former is good enough for you (or your customers) depends on your situation.
In case you want to understand what "inherently trusted" actually means for web browsers, see this blog post: Who your browser trusts, and how to control it.
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
One of our queue managers certificate is about to expire, it is been advised that renewing it is much cheaper than replacing the old one. These are the below steps which we are following(Through IBM Key Management):
Choose the personal certificate and select re-create - Renewal.csr
Send the Renewal.csr to CA for COMODO certificate - RenewedComodo
Choose the personal certificate and select Receive to import RenewedComodo. ( Refresh Security )
When creating a new certificate we opt for Personal Certificate Request and select new.This is the first step. and we follow the 2 and 3 steps.
Here is my query, other than selecting the re-create, there is no difference I had set up.
When I have two certificates as RenewalCOMODO and oldCOMODO, how do queue manager knows which is righteous.?
If it selects which is not expired, won't it be having the expired one in the database?
If we need to delete the old one, after adding the renewed one, How will it be different from replacing the certificates?
This will require a little background before getting to the answers.
When you initially created the CSR what you actually got was a public/private key pair and a Certificate Signing Request or "CSR". The CSR contains the public key and the requested attributes such as Distinguished Name. The CSR is signed with your private key so that any recipient can use the embedded public key to validate that the CSR and the requested attributes have not been tampered with.
What is less well known is that the CA is not bound to apply all the attributes that were provided in the CSR. For example, if the certificate purchased is a Domain Validated certificate and the CSR contains values for the OU field, the CA will simply delete them leaving only the DN and SAN fields plus their own information. Thus the certificate you get back may have different fields than the original CSR.
When you recreate the CSR from an in-use certificate the same process occurs again except that new CSR reflects any changes that the CA made originally. Close inspection of the original CSR and the newly generated one commonly show differences in the SAN or that an email contact has been added to the DN. However, from the CA's point of view these differences are cosmetic.
With that in mind, let's look at the questions again.
When I have two certificates as RenewalCOMODO and oldCOMODO, how do queue manager know which is right?
Assuming that you are talking about the artifacts the CA has provided after responding to the original and renewal CSR, the QMgr does not know which is which. You can run the receive command on either and, assuming both of them were signed by the same CA and use the same signer chain, either will work.
It is the administrator's responsibility to verify that the correct certificate is installed.
If it selects which is not expired, won't it be having the expired one in the database?
No. Each successful receive command keeps the private portions of the personal certificate and replaces the public portions. The label is associated with the private portion and this is checked for uniqueness so you cannot (or at least should not if there are no bugs) be able to have two copies in the same KDB.
If we need to delete the old one, after adding the renewed one, How will it be different from replacing the certificates?
Just make sure you receive the correct certificate. Always do a runmqakm -cert -details command or inspect the cert using the GUI.
Additional recommendations:
Always make a copy of the KDB before working on it.
Keep copies of your CSRs and certs in the KDB directory.
I like to use timestamps in the file names so it is obvious what the history was. My file names all start with YYYYMMDD like 20150908_QMName_CSR.arm and 20150908_QMName_CSR_signed.arm.
Make sure that the file permissions of the certificate files, KDB, and directory holding them are set to deny any access by anyone other than the MQM service account. If that's not possible, allow group access but make sure the members of the mqm group are as few as possible. Anyone who can read the certificates can use them. It is not necessary to know the password to the KDB to use the certs it contains.
When performing maintenance, I like to make a new copy of the KDB (with timestamped file name as described earlier) and when I'm sure it is ready I change the QMgr's SSLKEYR attribute to point to it. I then change the old file to be read-only and issue RESET SECURITY TYPE(SSL) on the QMgr.
Always remember to issue RESET SECURITY TYPE(SSL) on the QMgr. It is a rather disruptive command so try to not issue it when the QMgr is busy. It will require all channels to shut down and lots of reconnect attempts will prevent it from completing quickly.
I have been using a wildcard SSL certificate for several of my company's B2B websites for some time. Recently, we noticed that Google Chrome started displaying a red unlocked lock with HTTPS crossed out for all of these websites. The solution I found was to reissue the certificate from the provider (Network Solutions). So, I did this, and updated the certificate for each of the websites, and the Google Chrome issue went away (HOORAY!). However, when visiting any of these websites in Firefox, it displays a security message stating the website is using an invalid security certificate:
How can I resolve this so that our users are not confused when visiting these websites?
P.S. These websites are running on IIS6.
It looks as if the certificate chain is incomplete and, thus, Firefox (and likely other browsers) cannot verify the site certificate. Normally browsers store intermediate certificates they have seen in the past - that might be a reason why it works in Chrome.
You can test using https://www.ssllabs.com/ssltest/analyze.html.
Depending on the server software (here, for Apache httpd and other servers which read the certificate in PEM/DER format), you can just paste the intermediate certificates together with the certificate in one .pem file (which is used as Certificate file).
The chain (intermediate certificates) is/are normally provided by your CA. In your case you could also use Chrome the review the certificate and then store/extract all intermediate certificates from the certificate view.
You can get this certificate is not trusted error if server doesn't send a required intermediate certificate.
Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage.
If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet.
You can inspect the certificate chain via a site like this:
http://www.networking4all.com/en/support/tools/site+check/
I followed the instructions at enter link description here, to import the intermediate certificates.
In IIS, there is an option under Directory Security to "Enable certificate trust list". I enabled it and added the "AddTrust External CA Root" to the CTL certificates list and this appears to have fixed the issue.
I am interested in web security right now. So I read about PKI and Diffie Hellman authentication forms.
Now I am reading about certificates and I ask me how that works. So I know Browser have some trusted certificates in it, so you trust the pages, the company which the browser is from, trusts already. So when A trusts B and B trusts C --> A trusts C. Standart Web-of-trust thing.
But what I don't get is how for example google did it when they made there applications https. I never had to download a certificate. How works that?
There are a number of commercial bodies whose business is the issuance of digital certificates; these are called "Certificate Authorities" or CAs. The certificates of the top-level keys of these bodies are distributed with the common web browsers, so you will already have them installed.
If you (or Google, or anyone else) want a certificate for your key you send a request (and some money) to one of the well-known CAs. The CA performs some checks to verify that you are who you say you are, and (as long as the checks check out) they make a new certificare by signing your key with their certificate-signing key.
When you send your certificate to some third party they can check your certificate using the CA's certificate stored in their browser, and this allows them to establish that the identity you claim in your certificate is correct.
There are various levels of certificate which carry different levels of guarantee that the identity claimed in the certificate is correct. Basically, the more you pay the more trouble the CA takes in checking your identity and the more insurance they buy!
All browsers store certificates of Certification Authority, who in turn issue certificates for various organizations.