Working on cert related stuff and was wondering if there is a way to tag/hash/something in a unique way that could make lookup of a cert's parent signing cert faster than going through lookup of all the certs in folders? I'm looking for some kind of unambiguous and unique indexing method so that when I read a cert to validate it, I can extract information from some fields and quickly associate it with the parent cert to quickly resolve the chain assuming I have properly indexed the certs with that same unique key (index value could be used in filename or a database or other).
I noticed that on ubuntu when you look at /etc/ssl/certs there is a bunch of symlinks which look like perhaps a crc32 of some sort that links to the certs
lrwxrwxrwx 1 root root 12 Mar 9 2016 e113c810.0 -> Certigna.pem
lrwxrwxrwx 1 root root 25 Mar 9 2016 e18bfb83.0 -> QuoVadis_Root_CA_3_G3.pem
lrwxrwxrwx 1 root root 36 Mar 9 2016 e268a4c5.0 -> AddTrust_Low-Value_Services_Root.pem
lrwxrwxrwx 1 root root 49 Mar 9 2016 e2799e36.0 -> GeoTrust_Primary_Certification_Authority_-_G3.pem
lrwxrwxrwx 1 root root 25 Mar 9 2016 e36a6752.0 -> Atos_TrustedRoot_2011.pem
lrwxrwxrwx 1 root root 25 Mar 9 2016 e442e424.0 -> QuoVadis_Root_CA_3_G3.pem
I'm aware of the cert thumbprint/fingerprint but that isn't what I'm looking for and seems only to serve as a further validation of the cert contents itself.
Thanks
You can use hash of the issuer's public key. It is presented in leaf certificate as a prt of Authority Key Identifier certificate extension. It contains a hash calculated over issuer's public key. In CA certificate, this value is stored in Subject Key Identifier.
If AKI extension is missing, the only way to bind certificates in the chain is to use name match. Issuer field in leaf certificate must match Subject field of the issuer. However, if CA maintains multiple CA keys, there might be several CA certificates with the same subject, but with different keys. In this case, you will have to try each matching issuer candidate and attempt to validate the signature.
This means that you should maintain two indexes: by a hash of issuer's public key and issuer's Subject field to speed up certificate lookup.
Related
I am trying to run Nginx on Openshift but facing this directory permissions issues. Due to this error container is not creating.
The following permissions are set to files created manually.
drwxr-xr-x. 3 root root 79 Dec 22 02:50 /etc/nginx
drwxr-xr-x. 2 root root 26 Dec 22 02:50 /etc/nginx/conf.d
-rw-r--r--. 1 root root 5231 Dec 22 02:48 /etc/nginx/mime.types
drwxrwxr-x. 3 root root 25 Dec 22 01:23 /var/cache/nginx
drwxrwxr-x. 2 root root 6 Dec 22 01:10 /var/log/nginx
drwxrwxr-x. 47 root root 1340 Dec 21 06:51 /var/run
like #dbaker mentioned, RedHat being a security company makes their decisions in openshift regarding security more serious or aggressive as one might say, like for example running containers by default with running with random UID's.
you can fix that by reassigning the paths for different Nginx uses.
changing the PID location:
pid /tmp/nginx.pid;
changing the client temp location (your issue):
client_body_temp_path /tmp/nginx/client_temp
and any other paths in a similar fashion.
you can also use the unprivileged nginx image from docker hub aside from the image specified in the other answer from by RedHat as a certified image, ones that should play more nicely with RedHat products oriented towards security. as the other image is due to being deprecated I'm including the other tag recommended by RedHat rhscl/nginx-120-rhel7
Which specific container image are you trying to run? If you use this one -- https://catalog.redhat.com/software/containers/ubi8/nginx-120/6156abfac739c0a4123a86fd -- it will play nicer with OpenShift out of the box.
This sort of problem is almost always due to OpenShift running containers as non-root by default. If you change file permissions to permit write access to GROUP=0 you'll resolve nearly all of them.
We are a group of uni students and we're currently developing a project involving the creation of a private tor network.
So far we have created 2 server authorities successfully and we want to create a middle node to check if the consensus can be generated, but we have a problem that we cannot solve and we seem to not find any documentation about:
Nov 21 18:17:34.000 [warn] Bad v3 identity digest 'v3ident=8ExA7smGhHOiDwEttS04pkINWRh72YBMJB7XOMaF7ww' on DirAuthority line
Nov 21 18:17:34.000 [warn] Bad v3 identity digest 'v3ident=3i+SLxtN6rKnEjLVBLy23BrX9e9YrqrMKdFYSaUShGc' on DirAuthority line
those 2 lines are from the middle node's log file, and refer to the two identity servers that we have specified in the torrc file of the middle node, the mentioned file is:
UseDefaultFallbackDirs 0
DirAuthority alejandro orport=6969 v3ident=8ExA7smGhHOiDwEttS04pkINWRh72YBMJB7XOMaF7ww 172.31.22.112:9050 C71F 48D4 36BC E2BD FD74 521A F6DF F76F 1805 CF6E
DirAuthority marti orport=6969 v3ident=3i+SLxtN6rKnEjLVBLy23BrX9e9YrqrMKdFYSaUShGc 172.31.25.34:9050 23D2 7887 9F7C E57C 6ABC 60B7 6F9F F662 AF4F 5425
DirAllowPrivateAddresses 1
TestingTorNetwork 1
ExtendAllowPrivateAddresses 1
EnforceDistinctSubnets 0
AssumeReachable 1
ORPort 172.31.20.85:6969
DirPort 172.31.20.85:9050
All the elements of the tor network are inside a private network and we have tested the connectivity between the machines.
I have a Synology Diskstation DS216se running DSM 6.2.3-25426. I've installed MariaDB 10, Web Station, PHP 7.2, and myPhpAdmin, but when I open it at http://diskstation/phpMyAdmin/ I get this error message
"Sorry, the page you are looking for is not found."
I'm using an nginx server in Web Station, and the error log at /var/log/nginx/error.log contains multiple entries like the following
*621 open() "/var/services/web/phpMyAdmin/js/vendor/jquery/jquery.debounce-1.0.5.js" failed (13: Permission denied)
The file, and all other files with permission denied entries in the logs, exist in the /var/services/web/phpMyAdmin/ directory - what permissions need to be granted to the directory for this to succeed?
I hit this as well. I managed to recover, but it effectively amounts to hard clearing any evidence of prior installs of Web Station, PHP 7.2, phpMyAdmin, and any other web related services. Then manually ripping out some bad directories with broken symlinks/permissions.
My hypothesis is that I tried to install adminer prior to this and - having not done any set up for Web Station et. al. - it put the filesystem in a bad state.
I am not willing to try installing adminer again to test this hypothesis.
What I did to fix this:
Backup what you need (e.g., any personal web site).
SSH into your diskstation. Please be aware of what you are doing and keep in mind the big picture. Don't go deleting random things.
Uninstall Web Station, PHP 7.2, Apache, phpMyAdmin, etc. Anything that Web Station would ultimately be inclined to read and serve up.
Verify that /var/services/web doesn't contain anything you care about, and delete it (sudo rm -rf /var/services/web).
Verify that /volume1/web doesn't contain anything you care about, and delete everything inside it (sudo rm -rf /var/services/web). You may need to chmod permissions for this - I ended up leaving the web directory itself intact, but nothing inside.
Reboot. Mount any encrypted disks, etc.
Check that /var/services/web now shows it is symlinked to /volume1/web, e.g. sudo readlink -e /var/services/web.
Also check permissions for /volume1/web, e.g. ls -al /volume1. It should be owned by root:root and have permissive (777) bits.
Install Web Station, PHP 7.2, and phpMyAdmin in that order.
After this, I could open phpMyAdmin and be served its log in screen.
Debugging notes:
For me, when I SSH in I see in the logs similar issues:
2020/12/17 10:36:35 [error] 32658#32658: *1028 "/var/services/web/phpMyAdmin/index.php" is forbidden (13: Permission denied),
ps says that the nginx workers run as the http user (uid=1023(http) gid=1023(http) groups=1023(http)).
The directory /var/services/web/ appears to be owned by root, both group and user:
# ls -al /var/services/web/
total 424
drwxr-xr-x 3 root root 4096 Dec 17 10:29 .
drwxr-xr-x 3 root root 4096 Dec 17 10:22 ..
-rw-r--r-- 1 root root 27959 Apr 13 2016 adminer.css
-rw-r--r-- 1 root root 82 Apr 13 2016 .htaccess
-rw-r--r-- 1 root root 387223 Apr 13 2016 index.php
drwxr-xr-x 10 root root 4096 Dec 17 10:29 phpMyAdmin
It's not clear to me how Web Station's nginx is intended to work at all given the mismatch - perhaps some set of actions I took prior caused it to decide to install with bad ownership.
I decided to leave everything owned by root, but changed group permissions so that http can access:
# chown -R root:http /var/services/web/
# chmod -R 775 /var/services/web/
This got past the initial error, but revealed a new one:
"/usr/syno/synoman/phpMyAdmin/index.cgi" is not found (2: No such file or directory)
Indeed, there was no trace of phpMyAdmin anywhere in that directory. Evidence of a bad install.
I decided to uninstall anything web related: phpMyAdmin, PHP 7, Apache (happened to be installed), nginx, and Web Station. Once I did, I still had two files in /var/services/web: adminer.css index.php.
I had tried adminer prior to this. In /var/services, there were symlinks to specific volume locations, e.g.:
# ls -al /var/services/
total 12
drwxr-xr-x 3 root root 4096 Dec 17 10:22 .
drwxr-xr-x 17 root root 4096 Dec 17 10:21 ..
lrwxrwxrwx 1 root root 18 Jan 20 2020 download -> /volume1/#download
lrwxrwxrwx+ 1 root root 14 Dec 17 10:22 homes -> /volume1/homes
lrwxrwxrwx 1 root root 24 Jan 20 2020 pgsql -> /volume1/#database/pgsql
lrwxrwxrwx 1 root root 13 Dec 17 10:22 tmp -> /volume1/#tmp
lrwxrwxrwx 1 root root 13 Dec 17 10:22 web
Interestingly, web was not symlinked. I fully deleted /var/services/web.
Looking over at /volume1, I do see a /volume1/web, again fully owned by root but with extremely constrained permission:
d---------+ 1 root root 52 Dec 17 10:14 web
There are only a few things in here, which look related to a blank install of Web Station. I fully deleted everything within /volume1/web, but left it as is. With everything maximally cleaned I rebooted.
Upon boot, /var/services/web was now symlinked to /volume1/web, which now also had useful permission bits (777), and owned by root:root. Maybe this was done by some boot recover process, who knows. (I still have nothing web related installed at this point.)
I installed Web Station, then PHP 7.2, then phpMyAdmin.
I had the same issue when accessing my server via
<name>.local/phpMyAdmin/
It worked when I accessed it via
<local ip>/phpMyAdmin/
Hi I have been trying non-dev mode to start up the nodes for corda V3.
Currently after starting the node, during restart I am experiencing an error of: java.security.cert.CertPathValidatorException: The issuing certificate for C=UK, L=London, O=NetworkMapAndNotary has role NETWORK_MAP, expected one of [INTERMEDIATE_CA, NODE_CA]
the roles that I followed is provided in this link: https://docs.corda.net/head/permissioning.html#certificate-role-extension
obtained from OID Corda Role (1.3.6.1.4.1.50530.1.1)
Any pointers for this issue?
When i followed Devmode and assign my NetworkMapAndNotary to (Role 4) it fails to startup with the error: java.lang.IllegalArgumentException: Incorrect cert role: NODE_CA at net.corda.nodeapi.internal.network.NetworkMapKt.verifiedNetworkMapCert(NetworkMap.kt:48) ~[corda-node-api-corda-3.0.jar:?]
on a side note: i tried to follow devmode cert creation and noticed that the devmode (NetworkMapAndNotary) cert is tagged under a node ( role 4 ) why is that so..
Certificate[2]:
Owner: O=NetworkMapAndNotary, L=London, C=UK
Issuer: C=UK, L=London, OU=corda, O=R3, CN=Corda Node Intermediate CA
Serial number: 39551bff61207fb6
Valid from: Mon Mar 26 07:00:00 ICT 2018 until: Thu May 20 07:00:00 ICT 2027
Certificate fingerprints:
MD5: D1:8C:4D:83:F2:A7:F4:DA:60:05:E3:69:2C:30:FF:20
SHA1: E5:4D:01:A5:68:01:73:59:8B:7A:3D:0B:28:4E:35:C4:CD:DE:C7:52
SHA256: 3F:D6:24:E5:C8:9F:BE:EE:D4:99:D7:2C:85:50:F0:A8:26:46:84:D7:FB:3A:42:54:F2:12:64:51:48:58:FD:CF
Signature algorithm name: SHA256withECDSA
Version: 3
Extensions:
#1: ObjectId: 1.3.6.1.4.1.50530.1.1 Criticality=false
0000: 02 01 04
I resolved it by assigning two different certificates by following this diagram: https://docs.corda.net/_images/certificate_structure.png
Basically I need to create two certs instead of one.
self sign certificate for network map ( network map role )
another signed certificate for nodeca ( node role )
An issue here was because of Corda's tool networkBootStrapper.kt file comes with a hard code function inside the function of: installNetworkParameters where it will always call: createDevNetworkMapCa() function to generate a dev key pair regardless if I am in dev-mode or not.
Customize the file to use the self-signed certificate for network map adding on the role-extension. so the node certificate still remains but the network Map will be a one-time used key just to generate the network-parameters file for each nodes, the node role will always be used for node startup.
It was failing restart because it was seeing that there was a networkmap role certificate acting as another node role in the network.
The Network Map has been redesigned in Corda V3. Take a look at the following blog post and the docs here
Try removing the Network Map identity
guys i have looked and searched and read. yum update changed a permission somewhere but cant find where. Nagios on centos starts correctly i can view the page but for some reason i dont see any hosts or services, only 403 forbidden in the corner.
ive checked my nagios.cfg and no errors or warnings. I have started Nagios as daemon, same. Any other suggestions ?
total 160
drwxrwxr-x 5 root root 4096 May 7 18:14 .
drwxr-xr-x. 78 root root 4096 May 8 22:38 ..
-rw-rw-r-- 1 root root 11339 Sep 23 2014 cgi.cfg
-rw-rw-r-- 1 root root 11658 Aug 30 2013 cgi.cfg.rpmnew
drwxr-x--- 5 root nagios 4096 Aug 30 2013 conf.d
-rw-rw-r-- 1 root root 43443 Oct 2 2014 nagios.cfg
-rw-rw-r-- 1 root root 44533 Aug 30 2013 nagios.cfg.rpmnew
-rw-r--r-- 1 root root 960 Jul 24 2016 nrpe.cfg
-rw-r--r-- 1 root root 899 Mar 31 2015 nrpe.cfg.rpmsave
-rw-r--r-- 1 root root 5332 Feb 24 2015 nsca.cfg
drwxr-x--- 2 root nagios 4096 May 7 17:39 objects
-rw-r----- 1 root apache 27 Aug 30 2013 passwd
drwxr-x--- 2 root nagios 4096 May 7 18:14 private
-rw-r----- 1 root root 1340 Aug 30 2013 resource.cfg
-rw-r--r-- 1 root root 1628 Mar 20 2013 send_nsca.cfg
the check configuration :
Nagios Core 3.5.1
Copyright (c) 2009-2011 Nagios Core Development Team and Community Contributors
Copyright (c) 1999-2009 Ethan Galstad
Last Modified: 08-30-2013
License: GPL
Website: http://www.nagios.org
Reading configuration data...
Read main config file okay...
Processing object config directory '/etc/nagios/conf.d'...
Processing object config directory '/etc/nagios/conf.d/servicegroups'...
Processing object config file '/etc/nagios/conf.d/servicegroups/jira-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/routers-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/ups-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/backup-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/clone-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/perforce-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/linux-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/web-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hostgroups.cfg'...
Processing object config directory '/etc/nagios/conf.d/hosts'...
Processing object config file '/etc/nagios/conf.d/hosts/servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/test.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/diskstation.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/clone-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/wifi.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/cloud.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/perforce-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/printers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/switches.cfg'...
Processing object config file '/etc/nagios/conf.d/contacts.cfg'...
Processing object config directory '/etc/nagios/conf.d/commands'...
Processing object config file '/etc/nagios/conf.d/commands/notifications.cfg'...
Processing object config file '/etc/nagios/conf.d/commands/perfdata.cfg'...
Processing object config file '/etc/nagios/conf.d/commands/checks.cfg'...
Processing object config file '/etc/nagios/conf.d/commands/nrpe.cfg'...
Processing object config file '/etc/nagios/conf.d/templates.cfg'...
Read object config files okay...
Running pre-flight check on configuration data...
Checking services...
Checked 124 services.
Checking hosts...
Checked 23 hosts.
Checking host groups...
Checked 8 host groups.
Checking service groups...
Checked 8 service groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 1 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 27 commands.
Checking time periods...
Checked 1 time periods.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
finally what i see :
what is see
thanks in advance.
Looks like your permissions are all messed up!
When you installed it.. was it from source? If so, did you use the --with-nagios-user= flag during ./configure?
On one of my boxes I have a combination of apache and nagios as the /usr/local/nagios owners. Try this:
chown -R nagios:nagios /usr/local/nagios
chown -R apache:nagios /usr/local/nagios/etc
chmod +x -R /usr/local/nagios/bin /usr/local/nagios/libexec
You'll also want to make sure that the nagios user and group is set in the main configuration file (/usr/local/nagios/etc/nagios.cfg), like this:
nagios_user=nagios
nagios_group=nagios
Also, did you remember to set up your htpasswd file?
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Anyway, hope this helps get you started!