I am currently trying to build a production hyperledger-fabric setup. Therefore I am using a CA instead of cryptogen.
My structure looks like this:
orderer
org1
peer0.org1
peer1.org1
org2
peer0.org2
peer1.org2
and I have 2 CAs (1 for every org).
I have registered and enrolled orderer, peer0.org1, peer1.org1 and Org1Admin #CA1
and peer0.org2, peer1.org2 and Org2Admin #CA2.
The orderer has ROOT_CERTS of both CAs.
But how can I create the orderer genesis block based of those MSPs?
The configtx.yaml asks for an 'MSPDir' when describing the organizations, but I don't have an MSP directory for the organization itself, I only got the MSPs of the identites. Do I have to set up a specific folder structure for this?
you should create a msp directory for each of the organizations, including admincerts and cacerts.
if your tls is enable, you need tlscacerts.
if you have Intermediate CA, you need intermediatecerts too.
you can read this document for complete information.
You need to manually setup the MSP folder structure for an organization. Typically for any organization without TLS enabled and no Intermediate CA, it should have cacerts folder, admincerts folder. cacerts folder root CA certificates, admin certs hold the admin certificates for that organization.
You need to point MSPDir in configtx.yaml to this organization msp folder.
Related
I understand "certificate chain provided by the peer", if certificate provided by the peer is in the X509TrustManager, the certificate is trusted, so is it just need a checkTrusted instead of checkClientTrusted and checkServerTrusted, i don't understand what's the difference? Can anyone explains?
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509TrustManager.html
void checkClientTrusted(X509Certificate[] chain, String authType):
Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for client SSL authentication based on the authentication type.
void checkServerTrusted(X509Certificate[] chain, String authType):
Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for server SSL authentication based on the authentication type.
In the early SSL/TLS protocols that existed when JSSE was designed, there was a significant difference between the constraints on and thus validation of server cert (linked to the key_exchange portion of the ciphersuite) versus client cert (mostly independent of key_exchange but controlled by CertReq); see rfc2246 7.4.2 and 7.4.4 (modified by rfc4492 2 and 3). Although authType is a String in both checkServer and checkClient, the values in it and the processing of them in the default TrustManager were significantly different.
TLS1.2, implemented (along with 1.1) by Java 7 and early 8, changed the cert constraints to also use a new signature_algorithms extension (from client) and field (from server) in combination with the prior fields. As a result in Java 7 up the interface you link is functionally replaced by a subtype class https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html which in addition to the new constraint checks also moves to the JSSE layer only in checkServer the hostname checking aka endpoint identification formerly done at a higher level like HttpsURLConnection (if at all). The extended class additionally takes an SSLSocket or SSLEngine argument (as applicable) which allows access to the additional information for sigalgs and hostname.
Finally TLS1.3, implemented in java 11 up and backported to 8u261 up, uses only extensions, now two of them, and not the ciphersuite at all, for cert selection and checking. In 1.3 the extended API is still called but the value in authType is meaningless and must not be used, and in at least some cases I have looked at is in fact empty, so the actual (rfc5280) validation is in fact the same for both directions. But as above checkServer does endpoint identification if applicable while checkClient does not.
See an actual difference in https://security.stackexchange.com/questions/158339/ssl-tls-certificate-chain-validation-result-in-invalid-authentication-type-d (note: 2017 was before TLS1.3 existed)
and compare javax.net.ssl.SSLContext to trust everything sslContext.init(keyManagerFactory.getKeyManagers(), ???, new SecureRandom()); .
I did a "renew Cert" on one of my Enterprise subCAs, and it's totally messed up my results on Enterprise PKI in MMC. In the Certificate Authority snapin, there are now two certs (Certificate #0 and #1). The AIA (ldap) is showing "Unable to Download", with the "original CN=". The CDP (ldap) location has a (1) on it, as does the DeltaCRL. Every time I renew the revocation, it makes both the original cert's crl and a (1). The CDP/DeltaCRL (http) also both show "unable to download", even though the files exist in the directory. The only AIA location that shows OK is the http location.
I need to get rid of the old CA cert (the #0), I'll re-push the new one out via a GPO once this all is resolved. I tried to remove the AIA via ADSIEdit, and then republish it via "certutil -dspublish" but that gives me a 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER) error. Trying to connect to the Configuration of the specific CA via ADSIEdit says "server is not operational". In ADSIEdit CN=CDP there are multiple entries, the normal "CA", a "CA-1", and a "CA-1(1)".
This is in our "Test" environment (luckily), but I need to get a proper process sorted out as I need to do this in two other forests. I'm actually tempted to just totally rebuild a new CA in the other zones instead of fighting with all of this.
All I'm trying to do is re-issue a subCA's cert, and get it to work correctly and report healthy in Enterprise PKI!
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\OMNI-
TST-CERTAUTH-01-CA-1\CRLPublicationURLs:
CRLPublicationURLs REG_MULTI_SZ =
0: 65:C:\windows\system32\CertSrv\CertEnroll\%3%8%9.crl
CSURL_SERVERPUBLISH -- 1
CSURL_SERVERPUBLISHDELTA -- 40 (64)
1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
CSURL_SERVERPUBLISH -- 1
CSURL_ADDTOCERTCDP -- 2
CSURL_ADDTOFRESHESTCRL -- 4
CSURL_ADDTOCRLCDP -- 8
CSURL_SERVERPUBLISHDELTA -- 40 (64)
2: 134:http://pki.omni.phish/CertEnroll/%3%4%9.crl
CSURL_ADDTOCERTCDP -- 2
CSURL_ADDTOFRESHESTCRL -- 4
CSURL_ADDTOIDP -- 80 (128)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\OMNI-
TST-CERTAUTH-01-CA-1\CACertPublicationURLs:
CACertPublicationURLs REG_MULTI_SZ =
0: 1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
CSURL_SERVERPUBLISH -- 1
1: 3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
CSURL_SERVERPUBLISH -- 1
CSURL_ADDTOCERTCDP -- 2
2: 32:http://%1/ocsp
CSURL_ADDTOCERTOCSP -- 20 (32)
3: 32:http://pki.omni.phish/oscp
CSURL_ADDTOCERTOCSP -- 20 (32)
4: 2:http://pki.omni.phish/CertEnroll/%3.crt
CSURL_ADDTOCERTCDP -- 2
CRLPublicationURLs
1st, you're publish to the local disk (C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl) but nowhere else. Now you may have a manual process in place to upload this CRL to the CDP, in which case this is fine. Otherwise, you need to add another url (for example 65:file://\\[server]\[share]\%3%8%9.crl, where [server] is your CDP and [share] is a share for the directory containing your CRLs) so that new CRLs are automatically published to the CDP by the CA.
2nd, you are using a CDP of http://pki.omni.phish//CertEnroll/%3%4%9.crl. The %4 should be %8.
When you renew a CA certificate, you need the original CA certificate and CRL to still be available so that all end-entities that were previously issued certificates still work. Microsoft CAs do this by appending a (1) to the CRL name, just before the .crl extension for the 1st replacement certificate (Certificate #1 in the MMC) and (2) for the next renewal and so on. This is configured by the %8 in the CRLPublicationURLs registry key.
CAPublicationURLs
You are adding the URL to the CA certificate as http://pki.omni.phish/CertEnroll/%3.crt. You need to add a %4 after the %3.
The %4 does a similar job to what %8 does for CRLs. Without it, the CA certificate name remains the same.
There are three different ways you can fix these:
You can use the MMC - under Extensions on the CA Properties dialog. However, it's really clumsy to operate.
You can use the certutil -setreg command, but you have to overwrite all of the settings - you can't edit one line.
You can edit the registry directly at HKLM\SYSTEM\CurrentControlSet\Services\CertSrv\Configuration\[CA Name]
I find the latter is the simplest.
May I suggest some PKI and Microsoft ADCS revision before you touch production? :-)
I'd like to know if this example is enough to provide certificate pinning with libcurl:
http://curl.haxx.se/libcurl/c/cacertinmem.html
because I have found that curl also allows http://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
Since I'll be using a self-signed certificate and only trust on it I don't know if it's truly necessary to pinn it too.
resume: Can the connection be compromised if I only add my certificate (self-signed) to the x509 certificate store like the example? do I need to add extra checks? do I need to use the CURLOPT_PINNEDPUBLICKEY option?
Thanks.
You can find another example in the implementation of the new curl option in git 2.8 (March 2016):
See commit aeff8a6 (15 Feb 2016) by Christoph Egger (siccegge).
(Merged by Junio C Hamano -- gitster -- in commit e79112d, 24 Feb 2016)
http: implement public key pinning
Add the http.pinnedpubkey configuration option for public key pinning. It allows any string supported by libcurl -- base64(sha256(pubkey)) or filename of the full public key.
If cURL does not support pinning (is too old) output a warning to the user.
The git config man page mentions:
http.pinnedpubkey:
Public key of the https service.
It may either be the filename of a PEM or DER encoded public key file or a string starting with 'sha256//' followed by the base64 encoded sha256 hash of the public key.
See also libcurl 'CURLOPT_PINNEDPUBLICKEY'.
git will exit with an error if this option is set but not supported by cURL.
With Git 2.34 (Q4 2021), HTTPS error handling is updated when it comes to SSL certificate pinning:
See commit 3e8084f (24 Sep 2021) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 97492aa, 11 Oct 2021)
http: check CURLE_SSL_PINNEDPUBKEYNOTMATCH when emitting errors
Signed-off-by: Ævar Arnfjörð Bjarmason
Change the error shown when a http.pinnedPubKey doesn't match to point the http.pinnedPubKey variable added in aeff8a6 ("http: implement public key pinning", 2016-02-15, Git v2.8.0-rc0 -- merge listed in batch #8), e.g.:
git -c http.pinnedPubKey=sha256/someNonMatchingKey ls-remote https://github.com/git/git.git
fatal: unable to access 'https://github.com/git/git.git/' with http.pinnedPubkey configuration: SSL: public key does not match pinned public key!
Before this we'd emit the exact same thing without the " with http.pinnedPubkey configuration".
The advantage of doing this is that we're going to get a translated message (everything after the ":" is hardcoded in English in libcurl), and we've got a reference to the git-specific configuration variable that is causing the error.
Unfortunately we can't test this easily, as there are no tests that require https:// in the test suite, and t/lib-httpd.sh doesn't know how to set up such tests.
See this thread for the start of a discussion about what it would take to have divergent "t/lib-httpd/apache.conf" test setups.
I am trying to setup the certificate verification in opensips along with the blink sip client. I followed the tutorial:
https://github.com/antonraharja/book-opensips-101/blob/master/content/3.2.%20SIP%20TLS%20Secure%20Calling.mediawiki
My config look like so:
[opensips.cfg]
disable_tls = no
listen = tls:my_ip:5061
tls_verify_server= 0
tls_verify_client = 1
tls_require_client_certificate = 1
#tls_method = TLSv1
tls_method = SSLv23
tls_certificate = "/usr/local/etc/opensips/tls/server/server-cert.pem"
tls_private_key = "/usr/local/etc/opensips/tls/server/server-privkey.pem"
tls_ca_list = "/usr/local/etc/opensips/tls/server/server-calist.pem"
So i generated the rootCA and the server certificate. Then i took the server-calist.pem added the server-privkey.pem in there (otherwise blink sip client won't load it) and set it in client. I also set the server-calist.pem as a certificate authority in the blink. But when i try to login to my server i get:
Feb 4 21:02:42 user /usr/local/sbin/opensips[28065]: DBG:core:tcp_read_req: Using the global ( per process ) buff
Feb 4 21:02:42 user /usr/local/sbin/opensips[28065]: DBG:core:tls_update_fd: New fd is 17
Feb 4 21:02:42 user /usr/local/sbin/opensips[28065]: ERROR:core:tls_accept: New TLS connection from 130.85.9.114:48253 failed to accept: rejected by client
So i assume that the client doesn't accept the server certificate for some reason, although i have the "Verify server" checkbox turned off in my blink sip client! I think i have the wrong certificate authority file.
./user/user-cert.pem
./user/user-cert_req.pem
./user/user-privkey.pem
./user/user-calist.pem <- this 4 are for using opensips as a client i think
./rootCA/certs/01.pem
./rootCA/private/cakey.pem
./rootCA/cacert.pem
./server/server-privkey.pem
./server/server-calist.pem
./server/server-cert.pem
./server/server-cert_req.pem
./calist.pem
Can anybody help, did i do something wrong i the config or did i use the wrong certificate chain? What certificate exactly should be used by the client as a client cert, and ca authority cert?
Allright, i'm still not sure if it is working or not, because the authorization behaviour became weird, but after it's hanging for 5-6 minutes i get the success authorization, so this is a solution:
Generate rootCA:
opensipsctl tls rootCA
then edit server.conf file in your tls opensips folder and set the commonName = xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is your server ip address. Other variables can be edited in any way. Generate the certificates signed by CA
opensipsctl tls userCERT server
This will produce 4 files. Download the server-calist.pem, server-cert.pem, server-privkey.pem. Open the server-privkey.pem, copy it's content and paste in the file server-cert.pem, before the actual certificate. If you are using blink, the produced server-cert.pem goes in the preferences->account->advanced. And server-calist.pem goes into the preferences->advanced. After that restart blink and after 5-6 minutes your account is gonna be logged in. But i'v observed a weird behaviour, if you run another copy of blink and try to log into the other existing account after your logged from the first one with the certificates, you can log in from other account without providing the certificates. So i don't know, but i think it's working.
P.S. I asked about the certificates in the opensips mailing list, but i guess they found my question too lame, so i didn't get the response. If you have the same problem and got better results or an answer from opensips support let me know please.
How do I create a CMS (a.k.a. PKCS7) certificate?
The following bouncy castle code creates a PKCS12 certificate:
ASN1EncodableVector v = new ASN1EncodableVector();
v.add(tbsCert);
v.add(sigAlgId);
v.add(new DERBitString(signature));
X509CertificateObject clientCert = new X509CertificateObject(Certificate.getInstance(new DERSequence(v)));
PKCS12BagAttributeCarrier bagCert = clientCert;
bagCert.setBagAttribute(PKCSObjectIdentifiers.pkcs_9_at_friendlyName,
new DERBMPString("Certificate for IPSec WLAN access"));
bagCert.setBagAttribute(
PKCSObjectIdentifiers.pkcs_9_at_localKeyId,
new SubjectKeyIdentifierStructure(pubKey));
I see there is CMSSignedDataGenerator in the API, but I am not if it's applicable to my case and if so how....
I also don't understand why, if the created certificate is a PKCS12 one, then why do they use PKCS9 variables in order to built it.
There is no such thing as a CMS certificate or PKCS#12 certificate.
CMS is the cryptographic message syntax. It specifies a container format that may contain X5.09 compatible certificates of the signer. PKCS#12 is a container format for cryptographic objects, it is often used to store one or more certificate/private key pairs. PKCS#9 explicitly defines attributes for X5.09 certificates.
You probably just need to build an X5.09 certificate, possibly using PKCS#9 defined attributes. Those certificates should be compatible with both CMS and PKCS#12.