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? :-)
Related
I am attempting to upgrade EJBCA.
I attempted to run this on ubuntu 20.04, locally, using wildfly 18. Wildfly 18 results in this error: "CAUSE: Client certificate or OAuth bearer token required."
I have tried this two ways, by importing the keystore, truststore and superadmin from another instance and by creating the CA fresh and using the resulting superadmin.p12.
The home page loads, but the administration gives me the following error:
"AUTHORIZATIONDENIED
CAUSE: Client certificate or OAuth bearer token required. "
I can really use some help with this.
Things I have tried:
(1) I have downloaded superadmin.p12 and imported it into my browsers
(2) I have attempted to upload the superdmin cert:
bin/ejbca.sh ca importcacert ${NAME} ${NAME}.cacert.pem -initauthorization -superadmincn SuperAdmin
This results in The CA certificate is already imported.
(3) Both my keystore.jks and truststore.jks are moved into /ejbca/p12 and /opt/wildfly/standalone/configuration/keystore
(4) I did set "web.reqcertindb=false"
(6) I did try to enable ssl on wildfly 14 (https://docs.bitnami.com/bch/infrastructure/wildfly/administration/enable-ssl-wildfly/)
(7) I have tried a fresh Management_CA as well
The log of /ejbca/adminweb:
"08:20:01,270 ERROR [org.ejbca.ui.web.admin.configuration.EjbcaJSFHelperImpl] (default task-4) org.cesecore.authentication.AuthenticationFailedException: Client certificate or OAuth bearer token required.
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl] (default task-4) Language was not initialized for this session
08:20:01,279 WARN [org.ejbca.ui.web.admin.configuration.EjbcaWebBeanImpl]
I can provide more information if needs be.
Thank you
So, I have it running today. Here is what I learned:
It seems that if you set wildfly up as a service (per instructions) it is going to set up wildfly to run with launch.sh. Launch.sh is going to result in a cipher mistmatch. I needed to run the standalone.sh file instead
Adminweb must be contacted on 8443
if you need to run this thing on domain setup your going to need to post another question
Best,
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.
We had a perfectly working CAS (4.0) when we replaced an SSL cert with SHA1 encryption to SHA256.
We installed the cert and the new CA chain into the cacerts file. The subject (CN and all) are identical.
I go to my CAS protected site, I am correctly redirected to CAS, I can log in, and I get redirected to my site, but at that point I am redirected back to CAS, which thinks I am logged in... and endless loop.
Like I said, this was a perfectly working CAS before. Here is the relevant log:
FINE: Attempting to retrieve ticket [TGT-2-d7Z3hwQdJl4jWt0ZW1xCewqjgcdxxaCvIWzIvxueYcPJTuKXmN-XX.XX.XX.XX]
Jul 27, 2016 6:19:06 PM org.jasig.cas.ticket.registry.DefaultTicketRegistry getTicket
FINE: Ticket [TGT-2-d7Z3hwQdJl4jWt0ZW1xCewqjgcdxxaCvIWzIvxueYcPJTuKXmN-XX.XX.XX.XX] found in registry.
Jul 27, 2016 6:19:06 PM org.jasig.cas.web.flow.TerminateWebSessionListener sessionEnded
FINE: Terminate web session pC0up4YeyUpNO_e_CD_6NyJxMSq752luD8i9d3b8pZO_wR6Q9g3-!325246342!1469661546014 in 2 seconds
You can see it finds the ticket in the registry, but then terminates the session.
There are no errors or exceptions in the logs at all.
Any Ideas?
Look closer at the logs, and I will see that the service ticket has expired. Turns out, the bump from SHA-1 to SHA256 made the network trip from 6 seconds 13 seconds, and the TTL for the service ticket expired.
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.