HOWTO: Install/Configure msmtp and mutt on ubuntu
GTS CA 1O1 as the common name instead of
Google Internet Authority G2. What is the difference between the two.
GTS CA 1O1 refers to the one listed here https://pki.goog/?
GTS CA 1O1 valid until Dec 15, 2021. So by Dec 15, 2021, I should regenerate the local crt file by
openssl x509 -inform DER -in GTS1O1.crt -outform PEM -out gmail-smtp.crt
$ msmtp --serverinfo --tls=on --tls-starttls=off --host=smtp.gmail.com SMTP server at smtp.gmail.com ([126.96.36.199]), port 465: smtp.gmail.com ESMTP a10sm3703146oic.46 - gsmtp TLS session parameters: (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) TLS certificate information: Owner: Common Name: smtp.gmail.com Organization: Google LLC Locality: Mountain View State or Province: California Country: US Issuer: Common Name: GTS CA 1O1 Organization: Google Trust Services Country: US Validity: Activation time: Tue Nov 5 15:45:23 2019 Expiration time: Tue Jan 28 15:45:23 2020 Fingerprints: SHA256: 50:E7:13:03:7B:A8:D8:28:3C:D2:66:AC:58:E3:76:6D:BB:DB:E2:9D:B6:8F:54:38:10:BC:A5:93:67:25:7D:4D SHA1 (deprecated): F4:D9:49:8F:FA:F0:06:D1:B8:D7:AE:A8:56:A3:36:B4:FB:76:3E:32 Capabilities: SIZE 35882577: Maximum message size is 35882577 bytes = 34.22 MiB PIPELINING: Support for command grouping for faster transmission AUTH: Supported authentication methods: PLAIN LOGIN OAUTHBEARER
I have a website on Squarespace and the TLS certificate is set to expire in less than 24 hours.
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 Validity Not Before: Aug 10 18:38:10 2019 GMT Not After : Nov 8 18:38:10 2019 GMT
I understand that certificates from Lets Encrypt are limited to a 90 day lifetime, and that certificates are typically renewed around 60-80 days after being issued. Using certificate transparency logs I can see that Squarespace has indeed renewed the certificate, but the new certificate isn’t being served by their webservers yet. I reached out to Squarespace support and got this concerning non-answer, so I’m looking to better understand the situation now.
So long as your domain is active and connected to your Squarespace website using our recommended CNAME and A records (which you are), your SSL certificate will remain valid and you do not need to worry about expiration. Your SSL certificate refreshes every 90 days.
When does Squarespace usually renew certificates, and when do they begin serving them on their webserver?
“OpenSSH for Windows” version OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5 Client OperatingSystem Windows 10 Enterprise
Does OpenSSH for Windows support signed certs?
I feel like it does, as ssh-keygen picks up the certificate no problem. However, it doesn’t want to connect. The same steps seem to work fine from linux.
Directory of C:\hi 11/04/2019 01:18 PM 2,013 GregDFO-cert.pub 04/16/2019 09:07 AM 1,854 GregDFO-private.key 04/16/2019 09:31 AM 389 GregDFO-public.key C:\hi>ssh-keygen -Lf GregDFO-cert.pub GregDFO-cert.pub: Type: firstname.lastname@example.org user certificate Public key: RSA-CERT SHA256:Ccox9NCf/HBjzFxRE76XsnTT9k0vbmRB4/j5qX95WkQ Signing CA: RSA SHA256:3axo+wPqiszHOTKy94Tk2gj4S6Rb6uGWKcB4s059bvg (using ssh-rsa) Key ID: "root" Serial: 17890926214909873034 Valid: from 2019-11-01T08:52:18 to 2019-11-13T19:52:48 Principals: cormierg Critical Options: (none) Extensions: permit-pty
However, when trying to use it, ssh spits out invalid format
C:\hi>ssh -i GregDFO-private.key -i GregDFO-cert.pub email@example.com Enter passphrase for key 'GregDFO-private.key': ***** Load key "GregDFO-cert.pub": invalid format
A few extra verbose tidbits:
Enter passphrase for key 'GregDFO-private.key': debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering public key: GregDFO-cert.pub RSA-CERT SHA256:Ccox9NCf/HBjzFxRE76XsnTT9k0vbmRB4/j5qX95WkQ explicit debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: GregDFO-cert.pub RSA-CERT SHA256:Ccox9NCf/HBjzFxRE76XsnTT9k0vbmRB4/j5qX95WkQ explicit debug1: sign_and_send_pubkey: no separate private key for certificate "GregDFO-cert.pub" Load key "GregDFO-cert.pub": invalid format debug2: we did not send a packet, disable method debug1: Next authentication method: keyboard-interactive
High Availability Boot (HAB) is a technique described here in an NxP application note. This is best summarised as:
“HAB authentication is based on public key cryptography using the RSA algorithm in which image data is signed offline using a series of private keys. The resulting signed image data is then verified on the i.MX processor using the corresponding public keys. This key structure is known as a PKI tree. Super Root Keys, or SRK, are components of the PKI tree. HAB relies on a table of the public SRKs to be hashed and placed in fuses on the target.”
The procedure burns Super Root Key (SRK) fuses using a software tool called srktool. In it’s proper use, I would use an SSL certificate with the OID set for code-signing. This would have an oid of 188.8.131.52.184.108.40.206.3.
However, there doesn’t appear to be anything that stops me from using a certificate that is created for other purposes, e.g. for client authentication with the OID of 220.127.116.11.18.104.22.168.2.
The problem is that if I have two certificates from the same CA:
- Code-signing certificate
- Client certificate
I could sign the image with the code-signing certificate. If I could update the public key on the target device, then it would be possible to sign it with the client certificate and it would be accepted as valid.
The only option is use different CAs for both code-signing and client certs. I’m wondering if there’s some way to check the OIDs?
For testing purposes I want to test cross-signing certificates for Windows driver signing. I understand the general concept: Two root CAs, one root CA cross-signs the other root CA’s public key.
However, I couldn’t find any information on how to cross-sign the root CA’s public key exactly. When I simply sign the public key with the cross-certificate in OpenSSL, the cross-certificate is presented as the root certificate. Should it be like that? If not, does anybody what commands can be used to cross-sign a root CA’s public key?
Can anyone help me in signing the .sys files for windows 7 64 bits? I have created the self signed certificates using Openssl and I want to sign the the .sys files with that certificates using signTool.exe
I understand that Digital Certificates and Certificate Authorities (trusted 3rd parties) help prevent man in the middle attacks during HTTPS connections. However, I am confused on a few details.
Let’s say we have a client Alice and Bob who has a server mapped to “bob.com”.
When Bob (bob.com) asks a CA (let’s say veriSign) for a new certificate to be created and sends them his public key to be put inside the certificate, what is stopping a hacker from intercepting the request, switching the public key with their own, having the CA create a false certificate, and then returning this false certificate to Bob. Is the only protection here that Bob actually checks that the public key on the returned certificate matches what he originally sent in his request to the CA? And then I guess informing the CA that what he got back doesn’t match what he sent out, so the CA doesn’t maintain a false record?
Assuming that the newly created certificate Bob gets from veriSign is legit, let now say that Alice is going to make a request to “bob.com” via the HTTPS protocol. What is preventing a dual channel MITM attack where a hacker intercepts Bob’s new certificate on way to Alice, creates a new one, signs it with their own secret key (which was previously signed by verisign), but then also intercepts Alice’s request to veriSign when she asks for veriSign’s public key, and switches it out again with the matching public key to the malicious secret key. Now when Alice tries to check the integrity of the false certificate, it checks out because although she thinks she is checking the signature with veriSign’s public key, she is really using the malicious public key?
I have to install these three certificates (root.cer, server.pfx and client.pfx) genereted by Qlik Sense in a Ubuntu machine.
My cenario: https://help.qlik.com/en-US/sense/June2019/Subsystems/ManagementConsole/Content/Sense_QMC/configure-QDS-with-certificates.htm
The above link describes what I have to do for Windows, but I need the same result in Ubuntu. These steps works for Windows.
There are two diferents way to import, one for .cer and another for .pfx.
In Ubuntu should I consider “Trusted Root Certification Authorities” and “Automatically select the certificate store based on the type of certificate” steps diferences?
My search found lots of commands and conversions, but Im really lost about it.
What steps should I do to install these certificates?
This article from 2018 states (emphasis mine):
It is common practices for Kubernetes clusters to self-signed their digital certificates. I often get from Security Practictioners the hairy eyeball when this fact is discussed. Why not use “real” certificates, that are signed by trusted CAs. Well, some people do that, but for the rest of us, you are simply not gaining any signficant security benefits, and you are creating more work for yourself. You see, Kubernetes clusters use many digital certificates in all aspects of managaging a cluster. For example, each node has its own digital certificate to verify its authenticity.'
Is it still the correct approach to just allow EKS managed Kubernetes to create and deploy its own certificates?
I have to digitally sign a pdf. I created a little app using the DSS library (an EU project, based on
Bouncy Castle, very simple to use) that sign the PDF with
PADES using a
I know how to create a
p12 file from a certificate using
openssl. The problem is I only find Certificate Authorities that provides certificates for
There’s somewhere a list of official and trusted CAs that provides
X.509 certificates also for signing documents? I’m interested in pricing in particular… 😛
Thank in advance.