I see two common patterns of using -t switch argument for the certutil tool
certutil ... -t "CT,c,c"
and
certutil ... -t "P,,"
when taking care of self-signed SSL certificates for web servers.
Can anyone explain the difference between them and when to use one or the other?
Documentation lists possible values for -t switch
+ p - Valid peer
+ P - Trusted peer (implies p)
+ c - Valid CA
+ T - Trusted CA to issue client certificates (implies
c)
+ C - Trusted CA to issue server certificates (SSL only)
(implies c)
+ u - Certificate can be used for authentication or
signing
+ w - Send warning (use with other attributes to include
a warning when the certificate is used in that
context)
But I could not find any further explanation.
Related
This question already has answers here:
SSL working in chrome but sometimes in Firefox and not on IOS, Android or Blackberry
(2 answers)
Closed 1 year ago.
I've put together a Linux (Centos 7) server to serve eye-n-sky.net.
Serving content from that site to browsers on Win10 and Linux systems works beautifully. However, when I use openssl to access the site,
openssl s_client -connect eye-n-sky.net:443
the site certificate is rejected,
Verify return code: 21 (unable to verify the first certificate)
I've concluded that the way a browser verifies the certificate is different from what openssl does. Am I on the right track?
I've tested this on three different openssl instances (Debian, Centos, FreeBSD) and have consistent results.
Openssl as a client to other sites, e.g. www.godaddy.com, microsoft.com, work fine, being able to verify the certificate against the installed CA chain.
Believing that I was missing a CA cert, I used the -CAfile option to specify the possibly missing cert, to no effect.
What am I missing? I'm guessing that openssl has a stricter verification discipline, but I don't know where that gets configured.
Thanks,
Andy
Summary: yes, eye-n-sky was providing only it's cert when it needed to include the intermediate and root certs.
However, it took me forever to figure out that my Apache version did not support including the chain in the server cert file. Instead, I had to provide the chain file separately in an SSLCertificateChainFile directive.
OpenSSL's command-line s_client utility has nothing built in to validate the server's certificate. Browsers have a built-in list of trusted certificates to verify the server certificate against.
You have to supply the trusted certificates using options such as -CAfile file or -CApath directory. Per the OpenSSL 1.1.1 s_client man page:
-CApath directory
The directory to use for server certificate verification. This
directory must be in "hash format", see verify(1) for more
information. These are also used when building the client certificate
chain.
-CAfile file
A file containing trusted certificates to use during server
authentication and to use when attempting to build the client
certificate chain.
Note the use of words such as "certificate chain". If you go to godaddy.com you'll see that the server's cert is for *.godaddy.com, but it was signed by Go Daddy Secure Certificate Authority - G2, and that intermediate certificate was signed by Go Daddy Root Certificate Authority - G2 - a different certificate. There's a total of three certificates in that chain.
Verify return code 21 is "no signatures could be verified because the chain contains only one certificate and it is not self signed", so if your CA file only had the certificate from Go Daddy Root Certificate Authority - G2 and not the one from Go Daddy Secure Certificate Authority - G2, OpenSSL would see from the server's cert itself that it was signed by Go Daddy Secure Certificate Authority - G2 and could go no further - it doesn't have that cert to see who signed it.
I have a certificate chain as:
root CA -> intermediate CA -> org CA -> client Cert
When I verify the client cert with CA as root CA -> intermediate CA -> org CA, it works:
$ cat org_1_ca/ca_crt.pem intermediate_ca/ca_crt.pem root_ca/ca_crt.pem > /tmp/test123.pem
$ openssl verify -CAfile /tmp/test123.pem client/client_crt.pem
client_crt.pem: OK
But when I chained my client cert with org CA (org CA -> client Cert), and have the rest of the chain as CA (root CA -> intermediate CA), it doesn't:
$ cat intermediate_ca/ca_crt.pem root_ca/ca_crt.pem > /tmp/test12.pem
$ openssl verify -CAfile /tmp/test12.pem client/org1_client_crt.pem
client/org1_client_crt.pem: C = US, ST = CA, L = LA, O = PP, OU = TEST, CN = user
error 20 at 0 depth lookup:unable to get local issuer certificate
Is this something that fundamentally wrong or openssl verify doesn't like that? I tried the same thing with nginx and and openssl connect and there was no luck there. Any help is appreciated.
The openssl commandline verify operation reads only one certificate, the first one, from the file given as operand, or from each file if more than one is given. This differs from the files specified with the -CAfile -trusted -untrusted options which can (and typically do) contain multiple certs.
Your file client/org1_client_crt.pem presumably contains the client cert and the 'org CA' cert, in that order. Only the client cert is used, the 'org CA' cert is ignored, and as a result you do not have a valid chain to verify.
If you want to use commandline to mimic/test the validation that a receiver (for a client cert, the server) would do, supply the leaf cert as the operand and all other transmitted (chain) certs with -untrusted, and the anchor(s) plus any 'known' intermediates in the truststore either explicit or defaulted.
There is no openssl connect operation; I assume you mean openssl s_client with options including -connect since that's one place it would make sense to use a client cert chain. The -cert option to s_client similarly uses only the first cert in the file. There is no option on commandline to specify the client chain except in the most recent version, 1.1.0, and even there it isn't documented so you have to read the help message carefully or the code, although the API/library has long supported this for code you write yourself.
Through 1.0.2 if you want to send a client cert with full chain to the server (as you should per the RFCs), assuming the server requests client authentication which is not usual and not the default for nginx (among others), you have to use a trick: supply all the certs needed for the client chain in the truststore, in addition to the anchor(s) needed to verify the server, either using -CAfile and/or -CApath explicitly, or using (modifying if needed) the default truststore unless your openssl is an older non-RedHat version where the default truststore didn't work in s_client s_server s_time only.
And the same is true about the server cert/chain in s_server except that it is used almost always instead of very rarely.
I want to connect to ssl://iot.eclipse.org:8883 using Client certficate authentication.
How I can obtain CA certificate?
Do I require to generate my own client certificate with provided CA certificate.
Or client certificate is also bundled along with CA certificate.
Using openssl to check it appears that the certificate for iot.eclipse.org is from the Let's Encrypt project.
$ openssl s_client -showcerts -connect iot.eclipse.org:8883CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=iot.eclipse.org
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
So you should be able to check this certificate is valid with the standard CA set in most modern OS/Applications.
You will not be able to get hold of the CA cert/private key to generate your own client certs for obvious reasons and they do not issue client certificates ( and that is assuming that the eclipse.org broker is set up to authenticate clients with the same CA, it doesn't have to).
Also it doesn't make sense to authenticate against this broker as you have no way to set an ACL to control which users can subscribe/publish to specific topics as it's a public demonstration broker. If you want to secure access then you will have to run your own public broker
EDIT: You don't want to do client certificate authentication, you just want to verify the server cert, this is very different.
To do this with mosquitto_pub or mosquitto_sub you have to specify a CA cert or a path to a directory of multiple certificates in order to enable ssl/tls for the connection. You would specify an individual CA cert if you were using a private CA, but since the iot.eclipse.org broker is using a well known public CA you need to specify the path to the system collection of CA certs.
On Linux that is /etc/ssl/certs so you would publish as follows:
mosquitto_pub -h iot.eclipse.org -p 8883 --capath /etc/ssl/certs/ -t testing/ben -m foo
If a certificate is like a passport which proves your identity, then CA is just like a passport office(1). You could consider Verisign, Entrust etc as passport offices. CA certficate is analogous to passport office providing a way to check if a passport is valid or not.
To prove their identity any two parties,( read server and client ), could use certificates. To verify the authenticity of a party( read server ), you need CA certificate. Linux system(Ubuntu) holds commonly used CA certificates at /etc/ssl/certs.
A client certificate is needed only if you need to authenticate yourself to the server. Here server is iot.eclipse.org which doesn't ask for client authentication and so you don't need client certificate.
So, to communicate securely with server ( read TLS ), you can use the CA store present in your system(Ubuntu) as below.
mosquitto_pub -h iot.eclipse.org -p 8883 -t my_topic -m my_message --capath /etc/ssl/certs/
I have a PKI hierarchy like below.
root-ca ---> signing-ca ---> sub-ca-1 ---> server-cert-1 (machine 1)
\
\--------> sub-ca-2 ---> server-cert-2 (machine 2)
I wonder how to set up CA on each machine. For example, I create a bundle on machine 1.
$ cat sub-ca-1.pem signing-ca.pem root-ca.pem > cas-1.pem
cas-1.pem can verify server-cert-1 but it cannot verify server-cert-2.
So if machine 1 and 2 needs mutual authentication, it will fail.
Logically, I think the right way to do is that the certificate of machine 1 (and 2) should take up to sub-ca and the CA should start from signing-ca to root-ca (like below).
$ cat server-cert-1.pem sub-ca-1.pem > server-1.pem
$ cat signing-ca.pem root-ca.pem > cas.pem
But when I verify, it fails.
$ openssl verify -CAfile cas.pem server-1.pem
I am not sure how other SSL program will verify certificate.
Anyway, in situation like this, how to set up CA and certs on each machine such that verification can pass.
Thanks a lot.
it should be enough to either add the root-ca or the signing-ca to the CA store (e.g. the list of trusted CAs) on the client. The rest of the chain needs to be send by the server during ssl handshake, so that the client can verify the certificate up to the trusted CA.
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