I know it is possible to list server certificates from a client via openssl s_client -showcerts.

So, my question is, is it possible to create a valid ssl server certificate from this without needing to contact the server admin?

I have control of my client machine but not of the server so if I can avoid it, it would save trouble. I believe I need a .pem file and need a root certificate since using curl to access the server results in unable to get local issuer certificate.

If it not possible to do it, a kind application of why it is not possible would be appreciated, as am a bit out of my depth here. It seems to me only logical that it would be possible as the server has provided its certificate already.

openssl s_client -showcerts also outputs these errors:

verify error:num=20:unable to get local issuer certificate
verify error:num=27:certificate not trusted
verify error:num=21:unable to verify the first certificate

In essence, I would like to be able to make ssl as a client trust the server I am connecting to.

  • What do you mean with "create a valid ssl server certificate" ? One you could use to create your own SSL server? Then you would also need the private key for the certificate which the server does not provide. Jan 23, 2016 at 20:57
  • I am trying to figure out the error unable to get local issuer certificate from curl from a client and don't have server control, and as far as i understand its possibly indicating I have to add a root CA or some sort of server certificate. In openssl it says verify error:num=20:unable to get local issuer certificate verify error:num=27:certificate not trusted verify error:num=21:unable to verify the first certificate .
    – user55570
    Jan 23, 2016 at 21:40

1 Answer 1


IF your curl was built to use OpenSSL -- as you tagged but which is not the only option for curl, verify with curl -V -- AND the server is correctly serving any/all intermediate cert(s), THEN to trust the server curl-with-openssl needs a local 'truststore' containing the root cert for the server's cert chain (NOT the server's cert itself) in PEM format. (Some other SSL/TLS implmentations will accept nonroot anchor(s), but older versions of OpenSSL cannot do so at all, and even 1.0.2 doesn't do so by default.)

METHOD 0: maybe already there. Packages of curl often include a 'bundle' of widely-trusted CA roots such as Symantec GoDaddy etc., or link to another package that does (typically named something like ca-bundle or trusted-cas). The format(s) of the certs in such a bundle depend on the SSL/TLS library(ies) you use; check curl -V as above. Check if you have such a bundle installed, and if so whether your curl is using it. If you don't have or can't get a package (including the case you build curl yourself) AND use OpenSSL, curl upstream has a bundle of CA roots extracted from Mozilla NSS/Firefox extracted into the concatenated-PEM format needed for OpenSSL (and a tool to do this yourself).

openssl commandline need not use the same default truststore location(s) as curl -- and even if it does, until recent versions the s_client command had a bug that didn't use the default truststore correctly. If you do have a concatenated-PEM bundle, specify it to s_client with -CAfile bundlefile and see if that makes a difference.

If method 0 doesn't apply, you need to get the server's root and add it to your truststore, or just use it as a truststore by itself.

METHOD 1: get from browser. IF you can connect to the server with a browswer like IE/Edge, Firefox, Chrome, etc. (this requires there be a URL you can enter that the server will respond with a successful webpage), THEN doubleclick on the padlock and click on whichever buttons or links lead to displaying the certificate chain (exact ones vary per browser). Select the topmost cert in the chain and look for an option to export it, preferably in single-cert PEM format (again exact method varies per browser). If you can't get single-cert PEM format, comment what format you did get (give the first line if it looks like -----BEGIN something) and I'll tell you how to convert it.

Take this file (copy to the curl machine if you created it somewhere else) and either add it to your truststore (depends on your packaging system; may be a simple as concatenating it to the existing concatenated-PEM file) or specify it by itself to curl with option --cacert filename.

METHOD 2: s_client plus. Run openssl s_client -connect host:port -showcerts and capture (redirect or scrape) the output. Take the last block of lines -----BEGIN CERTIFICATE----- to ----END CERTIFICATE----- and put it in a file, for example topcert. If the s: and i: names (subject and issuer) immediately preceding this block are exactly the same, this is the root cert and you're all set. Use this file as above, but only if you are satisified this CA is honest and competent (even though they apparently didn't convince the browser makers if method 1 didn't work) because you are putting the security of your data in their hands.

If the top cert from the server is not a root, you need to get its parent cert, which must be the root. Alternatively, in some cases this is a 'bridge' or 'transition' cert that links a new CA back to another (older) CA, and there is also a sibling cert for the new CA that is a root cert. First do openssl x509 -in topcert -noout -text and look under x509v3 extensions then Authority Information Access for CA Issuers. If present, accessing this URL (or any of them) should provide the parent cert. This is usually in DER format; if so convert with openssl x509 -in input -inform der -out output.

Otherwise, look at any OCSP address(es), any CRL Distribution Point(s), and any URL(s) or domain name(s) in Certificate Policies or the Issuer name for the domain name(s) used by the CA and poke around there to try to find the parent root. Similarly look at any URL(s) or domain name(s) in Policies or Subject name and poke around for a sibling root. Or google for the Issuer name and/or Subject name. Or post the cert here. Or some combination.

  • After a lot of poking around, I managed to figure out how to properly add an item the truststore. But this wasn't the only issue. It looks like my openssl is v0.97 which does not support the encoding of the certificate. Having figured out all of that now, I believe I know what I need to do.
    – user55570
    Jan 24, 2016 at 6:28
  • I guess/hope you know 0.9.7 is at least 8 years old, depending on the letter which in OpenSSL is actually part of the version. Even so, cert encoding (both X.509 and openssl-PEM) hasn't really changed since 1997, so I'd expect that to work although it might ignore/skip newer extensions. The only thing I can think of offhand that probably wouldn't work is a cert using or for ECC signature i.e. ECDSA. Anyway, good luck. Jan 26, 2016 at 9:38
  • solaris 10 has only got v0.97 built in, so I suppose anyone else with solaris 10 will be in the same situation. About the encoding, an error I have seen is with v0.97 is verify return code: 7 (certificate signature failure). I've read somewhere only SHA1 is supported.
    – user55570
    Jan 26, 2016 at 19:31
  • Ouch! (0) I dug up some old versions and you're right 0.9.7 doesn't have SHA2. In addition to SHA1 it does have RIPEMD160, MD5, MD4 and MD2 -- but that's worse not better. I was also right it doesn't have ECDSA, but ECDSA is fairly easy to avoid today and SHA2 is not. (1) Per superuser.com/questions/649579/openssl-binary-for-solaris-10 there may be a newer openssl package for Sol 10. (2) Worst case, you can download source and build it yourself. I did one project using openssl on Sol 10 back around 2008, which for some reason I don't recall couldn't use sunfreeware, ... Jan 28, 2016 at 8:50
  • ... so we built from source and it was only about an hour and worked fine. You would probably need to (re)build curl to use the new openssl, and I can't testify to that but I've heard it's not bad. FWTW. Jan 28, 2016 at 8:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .