I have made CA Root certificate with "New-SelfSignedCertificateEx".
My problem is how to create domain/server/intermediate certificate which is slave to root?
Can you help me?
I have made CA Root Authority certificate. I use power shell instead makecert.exe command. I added into my trusted zone.
Now I want to create server CN=domain certificate which is extend CA authority. I need to sign and deploy on my IIS. How to do that with ps1 language?
|-----"My ROOT CA"
|
|--------"My Slave" (DNS CN=domain.local)
I thing I need to set "Issued to" and "Issued by".
"My ROOT CA"
Issued to - My ROOT CA
Issued by - My ROOT CA
"My Slave"
Issued to - My ROOT CA
Issued by - domain.local
Related
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
I am using Minikube/Kubernetes and want to add a new user. Therefore I need to sign the certificate request for a this new user. Where is the root certificate of Minikube located?
You can find your Minikube CA certificate(s) in your ~/.minikube directory.
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.
I maintain a java applet that is locally deployed. I recently purchased a code signing certificate from Go Daddy (it was inexpensive, and they already host our site). My certificate chain is as follows (all files are available at https://certs.godaddy.com/anonymous/repository.pki):
my company
gdig2.cer
gdroot-g2.crt
Unfortunately, this root is not installed by default on Windows 7 (used by IE) or the Windows JRE (used by other browsers, I think). Manually installing the root certificate is doable, but it requires my users to have administrator access or run unfamiliar commands (it also doesn't make much sense from a security standpoint to say "you can trust my applet, and to prove it, run this command on your computer").
I would like to change my certificate chain to
my company
gdig2.cer
gdroot-g2_cross.crt
gd-class2-root.crt
which seems to be more prevalent (for example, it is the one in the Windows JRE, and is used to validate https://www.godaddy.com, which gets it into Windows 7). Go Daddy is not able to do this for me ("our support for using one of our Code Signing Certificates is limited"), so I'm left doing this on my own.
Following this answer, my most promising approach has been the following (on Mac OS X 10.6):
Convert my certificate into pem format:
$ openssl pkcs12 -in myCert.p12 -out myCert.pem -nodes
Use a text editor to open myCert.pem, delete gdroot-g2.crt, and paste in gdroot-g2_cross.crt and gd-class2-root.crt (openssl appears not to care about the order of the certificates, but I put them in the order shown above)
Convert the certificates back to p12 format:
$ openssl pkcs12 -export -in myCert.pem -out combined.p12
Unfortunately, this doesn't quite work. Calling
$ keytool -list -storetype pkcs12 -keystore combined.p12 -v
shows that my certificate chain extends through gdig2.cer, and stops. The problem appears to be that gdroot-g2_cross.cer doesn't certify gdig2.cer:
$ openssl verify -CAfile gd-class2-root.cer gdroot-g2_cross.cer
gdroot-g2_cross.cer: OK
$ cat gd-class2-root gdroot-g2_cross.cer > gdRootCross.pem
$ openssl verify -CAfile gdRootCross.pem gdig2.cer
gdig2.cer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
error 20 at 0 depth lookup:unable to get local issuer certificate
But everything looks ok to me:
$ openssl x509 -in gdig2.cer -text -noout
. . .
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
X509v3 Authority Key Identifier:
keyid:3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE
. . .
$ openssl x509 -in gdroot-g2_cross.cer -text -noout
. . .
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=https://certs.godaddy.com/repository/, CN=Go Daddy Root Certificate Authority - G2
X509v3 Subject Key Identifier:
3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE
. . .
This leads me to think that I'm not using the cross certificate correctly, but I don't know what I'm doing wrong. (I've also tried appending the two new certificates to my original chain, to which openssl verify says error 18 at 0 depth lookup:self signed certificate.) I'm almost willing to believe that it's not possible to change the root certificate, but that seems to be the entire point of cross certificates. How can I introduce a cross certificate into my certificate chain in order to be verified by a different root certificate authority?
You don't. You just have one certificate signed by the first authority; and one certificate signed by the second authority - both are having the same public key / fingerprint and subject line. That's it.