I have one simple question and I will be very grateful if someone could help me. So when I run fabric-ca server, what sh -c 'fabric-ca-server init -b admin:adminpw' does is that it creates self signed certificate, and this will be root certificate for fabric-ca, under this certificate admin:adminpw user will be creted. so here is my question: why the hell I need ca-cert.pem and ca-key.pem files inside etc/hyperledger/fabric-ca-server folder? when do I use it?
The init command will create a self-signed certificate for the CA, but it has no association to admin:adminpw. That part of the command only registers a bootstrap identity with name of 'admin' and a password of 'adminpw'.
The ca-key.pem file is the secret key and will be used to sign certificates when identities enroll with the CA. The ca-cert.pem is the public component and is used in the verification of certificates, it comes into play when you define your channel and local peer MSPs.
Related
I'm trying to have a server A communicate with a server B through HTTPS requests. Server B has a certificate that was issued to me by my employer, and connecting to it through both Safari and Chrome works without any issues.
However, when trying to send a request from A to B through Guzzle, I get the following error:
GuzzleHttp/Exception/RequestException with message 'cURL error 60: SSL certificate problem:
unable to get local issuer certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)'
I've tried setting the cert file as a parameter ( [verify => '/path/to/cert.pem'] ), but, first of all, I only had .crt, .csr and .key files; I tried making a .pem file through these instructions I found somewhere else:
(optional) Remove the password from the Private Key by following the steps listed below:
openssl rsa -in server.key -out nopassword.key
Note: Enter the pass phrase of the Private Key.
Combine the private key, public certificate and any 3rd party intermediate certificate files:
cat nopassword.key > server.pem
cat server.crt >> server.pem
Note: Repeat this step as needed for third-party certificate chain files, bundles, etc:
cat intermediate.crt >> server.pem
This didn't work – the error's the same. The request works with 'verify' set to false, but that's obviously not an option for production.
Certificates are not something I usually work with, so I'm having a lot of trouble just figuring out where the issue might lie, let alone fix it. Any help would be much appreciated.
Edit
I've also tried the solutions suggested in Guzzle Curl Error 60 SSL unable to get local issuer to no avail.
This was happening because the only certificate I had configured on server B was the End User certificate.
I'm new to this, so my explanation will probably be flawed, but from my understanding End User certificates link back to a trusted Certificate Authority (CA) certificate, with zero or more intermediate certificates in-between. Browsers can figure out this certificate chain, and download the required certificates that are missing; cURL does not.
Therefore, the solution was configuring Server B with the missing certificates. How to do this is a whole different issue, so I won't go into it in this answer.
I am trying to obtain the root certificate of various websites for my project, but I am not sure the certificates that I am getting back with this command, contains root certificate or not?
openssl s_client -showcerts -connect google.com:443
I was searching for an answer when I came across a post where wget was used to get the root certificate from the certificate repository of godaddy
wget https://certs.godaddy.com/repository/gd_bundle.crt -O ~/.cert/mail.nixcraft.net/gd.pem
how do i find the repository for every website?
The server must include the certification chain during TLS connection (https). The chain may include the CA root certificate, but it is optional, So you have no guarantee that it will be available. The TLS protocol expects the client to have the certificate in their truststore to verify the trust
You can download the server certificate of every site programmatically, but it is needed to look for the root CA certificate. As you can see, godaddy publish them in its website. In many cases the certificate itself includes a reference to download the root certificate
I am unable to correctly configure Jenkins to use a StartSSL certificate.
I'm running it with command line arguments that specify paths to the private key and my certificate as shown on the Jenkins Wiki (at the bottom: https://wiki.jenkins-ci.org/display/JENKINS/Starting+and+Accessing+Jenkins).
I've obtained a private key and a certificate from StartSSL
I've placed them in a particular folder
I'm running Jenkins as follows: java -jar jenkins.war --httpPort=-1 --httpsPort=8080 --httpsCertificate=<mydomain.crt file> --httpsPrivateKey=<my private key file>
Jenkins starts successfully. Opening https://mydomain:8080/ in Firefox says that the connection is untrusted:
mydomain:8080 uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
I've tried verifying mydomain:8080 on various SSL checker websites:
OK mydomain resolves to xxx.xxx.xxx.xxx
OK The certificate was issued by StartCom.
OK The certificate will expire in XXX days.
OK The hostname (mydomain) is correctly listed in the certificate.
Not OK The certificate is not trusted in all web browsers.
You may need to install an Intermediate/chain certificate
to link it to a trusted root certificate.
StartSSL does not have explicit instructions for setting up Jenkins. I've tried following up on similar tutorials for other kinds of servers, and copied the intermediate authority files from StartCom into a unified certificate (ca.pem and sub.class1.server.ca.pem as noted here: http://www.startssl.com/?app=42).
However, this did not change anything.
SSL checkers like www.sslshopper.com/ssl-checker.html still report that the website is untrusted.
Also, the GitHub image caching service is not rendering the build status icon from Jenkins for the same reason.
How do I add the issuer chain correctly to my certificate?
I had a similar problem and after some research what got everything to be trusted was :
Merged the intermediate authority certificate and <mydomain.crt file> into 1 unified certificate called merged.cer using the link you mentioned
(From: https://serverfault.com/questions/569866/jenkins-wont-serve-with-ca-signed-certificate)
openssl pkcs12 -inkey /location/to/key.pem -in /location/to/merged.cer -export -out keys.pkcs12
keytool -importkeystore -srckeystore keys.pkcs12 -srcstoretype pkcs12 -destkeystore jenkins.jks
NOTE: the key to use for the merged.cer should be the same as <my private key file>
Then follow the Jenkins Wiki to use the KeyStore instead of the certificate
java -jar jenkins.war --httpPort=-1 --httpsPort=8080 --httpsKeyStore=/path/to/jenkins.jks --httpsPrivateKey=<my private key file>
I'm getting the error mentioned in this question:
The X.509 certificate CN=Farm chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust.
What I don't understand why I'm getting this error as the certificate I use for my request to the WCF service is added as shown below:
client.ClientCredentials.Peer.PeerAuthentication.CertificateValidationMode =
X509CertificateValidationMode.ChainTrust;
client.ClientCredentials.ClientCertificate.SetCertificate(
StoreLocation.CurrentUser,
StoreName.My,
X509FindType.FindBySerialNumber,
"MyCertificatesSerialNumber" );
The certificate itself is a self-signed certificate in the store shown above. When I click on it to show the certification path, no errors are shown (the root certificate is also a self-signed certificate). The root certificate was manually imported into the trusted root certification authorities.
From the error message I would have expected that there was an error in the certification chain with one of my certificates, but there isn't. Any ideas?
Update
I'm using Internet Explorer 9 as my browser to access the webservice. Programmatically I'm using a C# console application.
I had exactly the same problem - my own trusted root CA which signed another certificate. No errors were shown in the certificate store.
It turned out that having a trusted root CA and a certificate is not sufficient! You also need a certificate revocation list! Take a look at this MSDN Link.
So simply create such a .crl and add it also to the trusted root certificate authorities and everything works fine!
makecert -crl -n "CN=CARoot" -r -sv CARoot.pvk CARoot.crl
or simply turn of the revocation list check:
...RevocationMode = X509RevocationMode.NoCheck;
I had this problem - this is what I'd suggest:
On the server, make sure that the root cert is located on the "local computer" side of the computer, not "Current User". The other thing is that the SSL cert needs to be derived from the root cert. I eventually got it all to work using a script that included these lines:
rem creates root authority file and cert in localmachine\root and gives it the right to sign certs
makecert.exe -a sha1 -n CN=RootCert RootCertName -sr LocalMachine -ss Root -sky signature -pe -r -sk MyNewKey -cy authority
rem creates ssl cert, puts it in the currentuser\Personal store, signing it based on the root cert
makecert.exe -n cn=HostURL SSLCertName -is root -ic RootCertName -sky exchange -pe -sv SSLCertPrivateKeyName -eku 1.3.6.1.5.5.7.3.1
It's complicated, tedious stuff. You just have to keep at it.
I faced a similar issue while trying to connect to a self hosted WCF service using net.tcp binding. I already had the self signed root CA certificate installed in the CurrentUser certificate store, client was using a certificate signed by the root CA cert.
Installing the root CA certificate in LocalComputer certificate store fixed the error "A certificate chain could not be built to a trusted root authority". My WCF Server process runs using current user account hence this step was not obvious.
The next error was "The revocation function was unable to check revocation for the certificate"
To fix this, I created an empty Certificate Revocation List for the root CA cert and then installed the CRL in the LocalComputer certificate store. (Please check this link for details : https://msdn.microsoft.com/en-us/library/ff648732.aspx)
I also set the revocation check mode to Offline for both server and client certificates.
defaultCredentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.Offline;
defaultCredentials.ServiceCertificate.Authentication.CertificateValidationMode =
X509CertificateValidationMode.ChainTrust;
Now I don't have to turn off certificate validation or use different validation mode for development (In my case production code will also use self signed certificates for the time being)
I have been having this issue for about 2 weeks. I have done a lot of research and tried different ways but no joy. I have a development website on my computer (Windows 7 Pro) with sql server 2008 r2 and using IIS 7.5. There is an actual development server running the database and Webserver but because of my location I cannot use the main development site. I issued a self signed Trusted Root Certificate:
makecert -r -pe -n "CN=ROOT AUTHORITY" -ss my -sr CurrentUser -a sha1 -sky signature -cy authority -sv ca.pvk ca.cer
Then I install that into the trusted root on the local computer. After that I created a certificate for IIS to use.
makecert -pe -n "CN=example.website.name.com" -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -ic ca.cer -iv ca.pvk -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv server.pvk server.cer
Then I create the .pfx file for IIS
pvk2pfx -pvk server.pvk -spc server.cer -pfx server.pfx
After I do the above. I import the certificate into IIS and then I bind the website to the SSL certificate (server.pfx)
After all that is done, I go on the website https://example.website.name.com and I get 403.7 forbidden.
Can somebody please help me out with this issue?
take a look at some of these pitfalls...
Server Issue #1 - The client cert passed in has 1 or more certification paths that do NOT exist on the server. Open the cert go to certification path (tab) and make sure each of the root authorities are in the SERVERS trusted root certificate authorities. Note, you DO NOT need to install the cert on the server just the root authorities public keys under Certificates (Local Computer) \ Trusted Root Certification Authorities.
Server Issues #2 (previously mentioned solution) - In IIS, for the site, make sure the SSL Settings are set to Accept OR Require (never ignore). The benefit of using Require is that the IIS logs will show you are 403 7 error where as Accept will just get your the IsPresent == false but with a 200 http code.
Client Issue #1 - Same as server issue #1, got to trust those authorities!
Client Issue #2 - You have the trusted root authorites but NOT the private key for the cert itself. Make sure you install the pfx (private key) into the cert store not the public key (.cer). You can also see if you have the private key by double clicking the cert in the cert store and on the general tab you should see a message saying as much.
Client Issue #3 - You put the cert in the wrong place. Probably best to place your cert in Certificates (Local Computer) \ Personal \ Certificates, rather than (current user). This will make the cert available to process accounts that are running your code and actually need access to it.
Client Issue #4 - Right mouse click the cert (in the store not a .cer file) --> All Tasks --> Manage Private Keys... and make sure the process account running your code has "Read" permission. A quick test of this (but not recommended for production use) is to add "Everyone" as read to see if this is your issue