Github pages custom domain service automatically issue a Let’s Encrypt SSL certificate for https connection. my problem is, how to get the private key of this certificate? is it possible?
if the certificate is obtained by myself, the private key locate in /etc/letsencrypt/live, but github pages seem not support self obtained certificate.
That feature has been proposed since May 2018, and is part of the "Securing your GitHub Pages site with HTTPS"
It is a server-side (github.io) feature, which means the private key remains... private, on the server.
It should therefore not be possible to get it back.
Related
I know that if presented with an mTLS request an modern browser will request the user select a certificate from a store (OS-based or in Firefox's case NSS-based). I was wondering if there is any other way for the Webpage that is returned after the mTLS handshake to requests actions be performed with the users certificate or private key, such as:
Can the webpage be aware of the selected certificate and read some of the field with a Javascript API? (IE: <h1> Hello {x509CommonName}</h1>)
Can the webpage request that the user sign something with their private key? (little risky but potentially useful)
I am not asking how easy it is to just use the web server to reflect the certificate back to the client.
From the client side, it is not possible to obtain the certificate used in the SSL connection, nor to perform a digital signature. The browser keystore is not accessible via JavaScript. Although there has been some attempt to develop a standard API, it seems that it is not succeeding. See https://www.w3.org/TR/webcrypto-key-discovery/
On the server side you can easily obtain the certificate used. Any web server will provide it to the application layer. The web page could navigate to a zone with ssl two ways authentication, the server would retrieve the certificate and return it in the response
I already have a SSL certificate for my site and know how to redirect or convert my site into https.
But my question here is that. Is it a 'must', to convert the site to https in order to be secured? Or is it okay to retain using http but I should put the SSL certificate in the site so that even I type https, my site can still be visited and somehow it's also secured?
Sub notes:
http://www.sampleSite.com/ is the default link that I use in my site but if I type https://www.sampleSite.com/ it will also work though there will be no 'Secure' indicated besides my site link
Yes you should.
If you don't redirect http to https users will not redirect themselves.
Even if important pages (with personal information) that must be secured with https are redirected to https and the link pointing to them are https, because your pages with the link are using http, are vulnerable to sslstip.
If you want to properly secure your website, use https on all your webpage, redirect all http connection to https and use HSTS.
Anything less will be insecure and vulnerable to sslstrip attacks.
It depends of the use. If you web site use log in and sensitive informations, it's better to secure it.
The biggest difference between http and https is that
https encripte the online data. If anyone in between the sender and the recipient could open the message, they still could not understand it. Only the sender and the recipient, who know the "code," can decipher the message.
I see some website have changed the label on chromes ssl certificate, next to the url, from "Secure" to something else. Example: https://sunday.dk/ (Where the label is "Danske Bank A/S [DK]):
This is a particular type of SSL certificate called Extended Verification (EV)
An Extended Validation Certificate (EV) is a certificate used for HTTPS websites and software that proves the legal entity controlling the website or software package. Obtaining an EV certificate requires verification of the requesting entity's identity by a certificate authority (CA).
Have a look on Google for "extended verification ssl certificates" and you'll find lots of providers who will sell you one.
As a word of warning, there is quite a bit of admin in order to get the certificate issued. If you're familiar with buying normal SSL certs then this is a quick process and is mostly automated and takes a few minutes. I have spent a couple of weeks going back and forth to get an EV.
Does anyone know whether the certificate transparency feature as promoted by Google can/will apply to private installed CAs?
It seems like Chrome is already enforcing CT in some situations, presumably by auditing public CA logs. For private CAs that do legitimate Man-in-the-middle, there obviously won't be public CA auditing information, and it would be good to know that Chrome won't balk at that.
The CT enforcement policy applies only to public CAs, not self-signed or private CAs. The closest thing I could find confirming this was this tweet from Google's Ryan Sleevi.
CT enforcement policy also seems to be applied to internal EV certificates.
Whereas in Internet Explorer the addressbar is green with EV company name, and in chrome it is only listed as "Secure | https".
Still an issue, private certs does have issues with CT, as I've explained here:
Referrer policy hide the referrer of self-signed certificates
The official docs make it clear that Certificate Transparency only applies to CAs that are publicly-trusted - that is, CAs that are supported by your browser or device out of the box, without any additional configuration steps.
For CAs that have been manually installed, provided those certificates are not or have not been publicly-trusted, it‘s not necessary to enable support for Certificate Transparency. Further, Certificate Transparency Logs will not accept certificates from those CAs, thus it’s not possible to support CT.
Ref:
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/net/docs/certificate-transparency.md#Locally_trusted-CAs
I've created a certificate and a key using openssl, and using node.js to server a simple (hello world) file.
Chrome acts like the request never gets to the server (server logs too confirms).
Firefox warns about the certificate, but lets you access the file.
See attached image.
Any ideas?
OS: mac 10.9.5
Chrome: Version 41.0.2272.118 (64-bit)
The whole purpose of certificates is to be signed by a third entity, called a Certificate Authority (CA). A client will generally not accept a certificate given by a server unless the server produces a certificate signed by a CA specifically known to the client.
The 'identity' of a CA and the process of 'signature' are cryptographic concepts that are very precise and strict in order to avoid bad guys impersonating other people (your bank, Google, etc.).
Browsers usually allow you to accept untrusted certificates on a per-session basis, because bad certificates are everywhere and are not necessarily always a sign of malicious activity going on. However automatic code (Node.js included) will almost universally reject bad cetrtificates, because there's no way to ask a user for an override.
What you need to do is to generate a CA certificate and instruct you node.js client to trust it. I think the following links to a valid sample:
https://github.com/coolaj86/nodejs-ssl-trusted-peer-example. Look specifically at request.js - the relevant line is
fs.readFileSync(path.join(__dirname, 'certs', 'client', 'my-root-ca.crt.pem'))
Try to troubleshoot this further. Try other clients or an http(s) proxy.
Specifically I would try other browsers, https://github.com/iSECPartners/sslyze, Fiddler, curl, and other similar tools.