If I understand correctly, aws + graphql for mobile app is quite similar to Firebase Realtime Database. As the
firebase blog certificate pinning is supported behind the scenes. My question is: does graphql support certificate pinning?
Certificate Pining allows to bypass standard certificate authority chains to mitigate the risk of an valid certificate be issued to a criminal. It is now deprected. What Firebase has implemented and what you probably mean is Certificate Transparency (CT).
https://www.certificate-transparency.org/
Google's Certificate Transparency project fixes several structural flaws in the SSL certificate system, which is the main cryptographic system that underlies all HTTPS connections. These flaws weaken the reliability and effectiveness of encrypted Internet connections and can compromise critical TLS/SSL mechanisms, including domain validation, end-to-end encryption, and the chains of trust set up by certificate authorities.
Beginning April 24, 2018, AWS Certificate Manager (ACM) supports Certificate Transparency. See the following blog post for more details:
Preparing for AWS Certificate Manager (ACM) Support of Certificate Transparency
Certificate pinning is browser's feature.
And yes, almost browsers (Chrome, Firefox, ...) support Certificate pinning.
Related
How do browsers like Chrome check SSL Certificate?
IS there any online databases or websites that they use?
What steps are taken by browsers to validate a SSL certificate?
Am I able to do it manually without using browser?
How do browsers like Chrome check SSL Certificate?
The certificate and chain is send by the server during the SSL handshake. The browser will create the trust chain based on the certificate issuer, provided chain certificates and the local root certificates. It will check expiration and purpose of the certificate and also check the subject alternative names (and maybe subject too) to make sure that the certificate is actually issued for the domain in the URL. It might also do some checks for certificate revocation.
For details see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? and How Do Browsers Handle Revoked SSL/TLS Certificates?.
I there any online database or websites that they use?
Not really. The necessary trust store is local. They might check revocation though against some online resource. See Is Certificate validation done completely local?.
Am I able to do it manually without using browser?
Sure, what the browser does could in theory be replicated manually. You can for example access the site and get the leaf and intermediate certificates with openssl s_client -showcerts .... You can then use openssl verify to verify the certificate chain, see also Verify a certificate chain using openssl verify. Then you need to look at the leaf certificate with openssl x509 -text ... to check purpose, expiration and the subject. Revocation is tricky but could be done with the help of openssl crl and openssl ocsp, although this does not really reflect what browsers do.
The official algorithm for validating any SSL/TLS certificate is defined by PKIX as modified by OCSP. For TLS nowadays the OCSP token is often transported by 'stapling' in the TLS handshake instead of by a separate connection, which requires several other RFCs, but that only affects transport, not the actual validation by the relier. For HTTPS specifically, the client must also check server identity aka 'hostname' as defined by rfc2818.
In practice, browsers may vary some. Chrome mostly uses a google-determined scheme to 'push' revocation data they select, but this has changed from time to time. Firefox, last I heard, used their own 'one-CRL' scheme. Also, although the standard and traditional practice was to check hostname against SAN if present and otherwise fall back to Subject.CN, Chrome since a few years ago requires SAN and never uses CN; you can find dozens of Qs on several stacks about "my selfsigned or otherwise DIY cert not from a real CA stopped working on Chrome".
If by 'do it manually' you really mean manually, that will be a lot of work. If you mean with tools other than a browser offline, somewhat easier; OpenSSL (if installed) can do most of this, although you need more options than shown in Steffen's link to get it right.
If you mean with tools other than a browser online, absolutely. The WWW has become extremely popular in recent decades, and there are zillions of programs and libraries for accessing it, nearly all of them including HTTPS (although two decades ago that was less common), which includes validating the certificate -- at least by default; many have options to disable, bypass, or override validation. There are standalone tools like curl and wget -- or openssl s_client can do the SSL/TLS and certificate part without doing HTTP on top. There are innumerable libraries and middlewares like ssl in python (or requests using it), tls in nodejs, (older) HttpsURLConnection and (newer) java.net.http in Java as well as third-parties like Apache HttpComponents; I'm sure there are counterparts for perl and dotnet although I'm not familiar with them. As well as powershell, which is fuzzy on the program/library distinction.
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 have a website that works offline using service worker. I heard that, to make it live need a proper https certificate. How to get one https certificate? its free? Please Help.
There are 3 grades of TLS certificates:
Domain Authority
Organizational Authority
Enterprise Authority
They are all valid certificates, they just require a higher level of authentication to obtain. Most sties just need a DA certificate, which is validated via the whois e-mail. The other two take more vetting.
As far as SNI or not SNI that does not matter either.
All that matters is you have the TLS certificate to create that wrapper of encryption around the data packets.
You could use a certificate from the Letsencrypt organisation. It's free and reliable. I can recommend it.
Full disclosure, I asked this question over at Ask Different (https://apple.stackexchange.com/questions/96776/always-get-a-security-error-for-internal-https-website) but didn't get much helpful feedback. I'm hoping this question fits better here.
My company recently changed an internal site to use HTTPS instead of HTTP (it is our Jira site in case that matters). From what I can tell, this site is using an internal certificate. On our work computers this certificate appears to be pre installed so the website comes up without trouble in IE, Firefox, and Chrome. However, my personal computer is a Mac (OS X 10.8.4) and I am having major troubles accessing the site through any browser. I have followed instructions to install the certificate in my Keychain and I believe I have successfully done that, but I am still not able to access the site.
When Accessing the site I Get:
Chrome: Invalid Server Certificate You attempted to reach jira.surescripts.local, but the server presented an invalid certificate.
Safari: Safari can't open the page Safari can't open the page "https://jira.local:8081/" because Safari can't establish a secure connection to the server "jira.local"
In Chrome when I view the certificate information it I see: Intermediate certificate authority. Expires: Thursday, May 21, 2015 1:19:28 PM Central Daylight Time. This certificate is valid
To make sure that it wasn't something strange with our company's VPN, I installed a Windows 7 virtual machine on my Mac and installed the certificate in Windows and am able to successfully log on to the site how I always would.
I am not much of an expert with certificates and I really don't know where to go from here. Any help would be greatly appreciated! Thanks.
It almost sounds like you need to trust a self-signed certificate? Perhaps follow: https://confluence.atlassian.com/display/SOURCETREEKB/Resolving+SSL+Self-Signed+Certificate+Errors
Sefl signed certificate always triger warnings in web browsers.
To validate a server certificate you must have in the client browser the CA certificate wich was used to sign the SSL server certificate.
Your company should create a CA cert, then create a server SSL cert. signed with the CA and put it on the web server. The clients install public part of the CA cert in "Trusted CA" certificate store. When client conect to the web server the server sent the signed SSL certificate, the client check if it is a "trusted" cert (was signed by a trusted CA) and if everithing is Ok the client doesn't show the warning.
You ended with this cert chain:
CA cert->SSL cert
CA cert public part is installed in client broser as trusted CA. SSL is put in the web server. Client validate SSL cert agaist its Trusted CA certs installed in its Certificate Stores.
It is like CyberTrus CA. You can see how you have Baltimore Cyber Trust Root and Cybertrust Public SureServer SB CA installed in your computer and when you enter into https://www.bancosantander.es/cssa/Satellite?pagename=SantanderComercial/Page/SAN_Index you can see that *.bancosantander.es certificate is valid because you are trusting in the chain.
Your company needs to create the root, then create the SSL signed by the root. The root (public part) is distributed to the client for install. The server sends the SSL to client in HTTPS protocol.
Check this link for more info.
The problem is probably the encryption protocols that your Mac and the company web site don't match up.
Safari Browsers for OS X before Safari 7 (up to 6.0.7 which was on OS X 10.8.4) use the SSL 3.0 protocol, which has vulnerabilities and is considered insecure. Most newer and well-designed web sites use TLS 1.1 and/or TLS 1.2.
Browser encryption capabilities for Safari 6.0.4
Find out from your company if that is what is set up. The same site that has the specs I linked to allow you to enter a web site, and they'll throw a battery of test transactions at it to test it's security and what will connect, but I doubt you can use that for an internal site. Ask your IT folks what encryption protocols they are using.
As a solution, I believe there are versions of Firefox and/or Chrome that can run on 10.8.4 that use TLS 1.2.
List of major browser versions that support TLS 1.2
Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other