I have a (slight) working understanding of x509 certs and I've been trying to understand why the instructions I followed aren't working.
I followed https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html which simply says, connect with sslmode=verify-ca (or verify-full) and sslrootcert=$CERTPATH, where $CERTPATH is the path to cert they provide in the first paragraph of the guide. Doing that I get x509: certificate signed by unknown authority.
Debugging this a bit, I (with my bad understanding of x509) expected the RDS to respond with some cert with CN=*.something.us-west-2.rds.amazonaws.com (the database) issued by something like CN=Amazon RDS us-west-2 2019 CA with an intermediate for chaining the CN=Amazon RDS us-west-2 2019 CA cert to Amazon RDS Root 2019 CA and Amazon RDS Root 2019 CA is our sslrootcert.
What I see is a cert with CN=*.something.us-west-2.rds.amazonaws.com issued by OU=Server CA 1B, CN=Amazon and an intermediate from CN=Amazon,OU=Server CA 1B to Amazon Root CA 1 - Amazon's root cert on amazontrust.com from https://www.amazontrust.com/repository/AmazonRootCA1.pem. So psql "postgres://.../dbname?sslmode=verify-ca&sslrootcert=AmazonRootCA1.pem" works just fine.
Is Aurora misconfigured somehow? Am I doing something slightly wrong? I figure using sslrootcert=AmazonRootCA1.pem isn't terrible but I want to understand the piece I'm missing, mentally. Any help is appreciated.
I also got the error with the below rds bundle from Aurora Doc:
https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html
But i tried other ca cert given in same wiki and it resolved "x509 unknown authority" issue and client is able to verify root cert.
https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem
Related
I am creating New Kubernetes service connection in Azure DevOps Server 2020 Update 1 via KubeConfig.
When I click to Verify that the connection it says that Verification Failed with the generic error:
Failed to query service connection API: 'https://ekm.mpu.cz/k8s/clusters/c-qmcrb/api/v1/nodes'. Error Message: 'An error occurred while sending the request.'
Please note that the Kubernetess instance is in the other domain.
I have the notion that the error could be with the certs are not imported somewhere on the machine, where the Azure DevOps is hosted, but I am unsure where. The MS documentation is silent about that as well.
So far I've tried to:
Import CA certs to the MMC under trusted publishers.
Import CA certs under cacerts in JAVA-HOME via keytool.
Import CA certs into azureTrustsStore.jks in JAVA-HOME via keytool.
For all 3 I've checked that the CA certs are imported correctly. But to no avail. Could you please advice or redirect me to the method, how to do it?
Additional Info:
While I cannot Verify and Save the connection, I still can Save it and then use it in the pipeline and it works OK! (sucesfully connect and execute the command).
Connection issues can occur for many reasons, but the root cause is often related to an error with one of these items: Network, Authentication, Authorization. You may refer to Basic troubleshooting of cluster connection issues for detailed troubleshooting steps.
I have an ES Cluster(ES version 7.4.2) that has been running for 3 years.
when I run the following query.
GET _ssl/certificates
I'm getting the output.
"expiry" : "2022-11-20T07:27:29.000Z"
in /usr/share/elasticsearch
For the new 'temescls01-ca.p12' certificate
I run './bin/elasticsearch-certutil cert --ca /etc/elasticsearch/certs/temescls01-ca.p12' and when I enter the 'CA CERT password' it generates a new temescl01-ca.p12 certificate.
For the new 'temescls01-certificates.p12' certificate
I run './bin/elasticsearch-certutil cert /etc/elasticsearch/certs/temescls01-certificates.p12' and enter the 'keystore password'.
I'm using the old certificates' passwords for both new certificates.
I was able to create all 2 certificates. But when I stop the elasticsearch service and replace the old certificates with new certificates by following the document here, the node cannot join the cluster. When I replace the old certificate, the node joins the cluster without any problems.
An example from elasticsearch.yml
elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/temescls01-certificates.p12
xpack.security.transport.ssl.keystore.password: XXXXXXXXX
xpack.security.transport.ssl.truestore.path: certs/temescls01-certificates.p12
xpack.security.transport.ssl.truestore.password: XXXXXXXXX
Is there something i did wrong?
It’s not possible to extend the expiry date of a certificate. But you can create a new one. If you are using PKCS #12 format of SSL/TLS (p12) certificate you can use this article to create a new certificate.
https://medium.com/p/99820ff87615
Currently when you create a Cloud SQL instance, a self signed certificate is created per the Google Cloud SQL documentation.
Is there a way to choose a different Certificate Authority so my communications are signed by a trusted third party?
Below is a sample of the current cert created by Google when the instance is created.
Common Name: Google Cloud SQL Server CA
Organization: Google, Inc
Country: US
Valid From: November 26, 2018
Valid To: November 23, 2028
Issuer: Google Cloud SQL Server CA, Google, Inc
Serial Number: 0 (0x0)
You can connect to your instances using your own CA certificate.
If you have a MySQL instance, follow the steps in this page of the Google Cloud SQL documentation, where it says Connect to your Cloud SQL instance using SSL, but skip the creation of a new client certificate in the beginning.
You need to have the certificate in a text file (such as server-ca.pem) that you'll pass as a flag --ssl-ca=[CERTIFICATE-FILENAME] to the mysql command.
For PostgreSQL, follow these steps instead, again skipping the beginning and using your own CA cert. The cert file would be then indicated when running psql, which takes a string as an argument, including sslrootcert=[CERTIFICATE-FILENAME] in that string.
I am trying to setup some certificates for different hostnames (aliases) for SQL Server Reporting Services so that I can secure connections on my own machine for testing purposes. My understanding is that these certificates need to be signed by a trusted Root Certificate Authority (explained here). After doing some research, I've found a lot of helpful information that can generally be summarized by this post; the information I've found tells me how to create new certificates using Powershells New-SelfSignedCertificate cmdlet.
So now I know how to create a new Root CA, and I know how to create an SSL certificate for a given hostname which is signed by the new Root CA. However, I can't find anywhere that explains how to re-use an existing Root CA. I want the code to work like this:
$rootCA = <# What goes here? #>
$TestSigned = New-SelfSignedCertificate -subjectName "CN=TestSignedByRoot" -Signer $rootCA
Am I supposed to just create a new Root CA every time I want to create a certificate? That seems insane so I sure hope that's not the case. If any of you could provide some explanation and sample code it would be greatly appreciated.
To get a certificate from the certificate store with known hash:
$rootCa = ( Get-ChildItem -Path cert:\LocalMachine\My\EEDEF61D4FF6EDBAAD538BB08CCAADDC3EE28FF )
To see what certificates there are in the My store:
Get-ChildItem -Path cert:\LocalMachine\My
To get a certificate by subject name, use Where-Object to check the Subject property:
$rootCa = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {$_.Subject -eq "CN=My Awesome Root CA"}
You are missing a key word here: Trusted. Not just by you, but by any computer that tries to verify the validity of the certificate. Most companies will have a PKI solution to be able to issue certificates internally, and will have the certificate for the Root CA pushed out via GPO into the Trusted Roots folder of the local machine certificate store. The Root CA should be something that is already established, and trusted by the computers that will be connecting to your SQL server. I would recommend contacting your IT or Security department to ask about if the company has a Trusted Root CA that you can get your certificate signed by, or if they can issue you a certificate that chains to the trusted root.
Edit: Ok, I missed the point. My understanding was 'my machine' being the SQL server that you support vs other computers that would connect to it. If the only computer that you are concerned with is your own, then this comes down to:
Create a Certificate Signing Certificate (Certificate A)
Add Certificate A to the Trusted Root folder of your LocalMachine
certificate store
Create a self signed certificate (Certificate B)
using Certificate A as the signing certificate
Once you have completed steps 1 & 2 you can repeat step 3 as many times as needed to make additional certificates. You should only need 1 Root cert ever. The important part is that the Root certificate is trusted by the 'client', so that when it connects to the SQL reporting service and sees the certificate it can establish a chain of trust to the root certificate that initiated the chain.
To use an existing trusted certificate, you will need a copy of the trusted certificate in the Personal Certificates folder (cert:\LocalMachine\My) I used CertMgr. Else when you finally run your command to create the self signed certificate, you get an error
New-SelfSignedCertificate: CertEnroll::CSignerCertificate::Initialize: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
We have a root certificate authority made with OpenSSL. Its file-based, runs on RHEL, uses "serial" and "index.txt" etc.
Now in a lab environment we have added an intermediate standalone certificate authority using Active Directory Certificate Services, standalone (i.e. not an AD or domain member), running on Windows Server 2012 (all latest updates applied). We signed the intermediate CA with our root and ADCS is up and running successfully. But what we're finding is that we actually cannot issue any certs from this intermediate CA.
When we use the management console and attempt to issue a requested cert, the cert ends up in "Failed Requests" with the message:
Active Directory Certificate Services denied request 4 because The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614 CRYPT_E_NO_REVOCATION_CHECK).
The request was for CN=obelisk.sand.idfconnect.lan, OU=IDFC, O="IDF Connect, Inc.", L=Wilmington, S=Delaware, C=US. Additional information: Error Constructing or Publishing Certificate Resubmitted by OBELISK\Administrator
If I look at the request, I can see the is defined as:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=file:////obelisk.sand.idfconnect.lan/CertEnroll/Obelisk Intermediate CA.crl (file:////obelisk.sand.idfconnect.lan/CertEnroll/Obelisk%20Intermediate%20CA.crl)
If I use IE to browse that file:// url, it pops open Windows Explorer, where I see the files I'd expect, i.e.
nsrev_Obelisk Intermediate CA.asp
Obelisk Intermediate CA.crl
Obelisk Intermediate CA+.crl
obelisk.sand.idfconnect.lan_Obelisk Intermediate CA.crt
Lastly, when I view the properties of the intermediate CA from the MMC, and look at its certificate, at the bottom of the details it says: "Extended Error Information: Revocation Status : The revocation function was unable to check revocation for the certificate."
Any advice to get this intermediate CA working greatly appreciated!
Add the public root certificate to the machine store (certlm.msc) trusted root certificate authorities.
Add the public root certificate CRL to the machine store (certlm.msc) trusted root certificate authorities.