4

I became my own certificate authority after running through the tutorial at: https://jamielinux.com/docs/openssl-certificate-authority/

I created a root pair, created an intermediate pair, and signed a server certificate, which I installed on squid like this:

http_port 3129 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/certs/gatesentry.csr.cert.pem key=/etc/squid3/key/gatesentry.key.pem 

in squid3.conf

Squid starts up just fine with this. Still not sure if it's actually working or not.

When I try to generate a client-side certificate to install in a browser that will be accessing the internet through the proxy I end up with an error:

I generate it based on the "Sign server and client certificates" section that reads "Create a certificate"

It states that if I'm going to create a client certificate for authentication, I'll need to use the 'usr_crt' extension and so I run:

cd /root/ca openssl ca -config intermediate/openssl.conf \ -extensions usr_cert -days 375 -notext -md sha256 \ -in intermediate/csr/gatesentry.csr.pem \ -out intermediate/certs/client.cert.pem Using configuration from intermediate/openssl.conf Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4097 (0x1001) Validity Not Before: Jun 22 10:36:44 2016 GMT Not After : Jul 2 10:36:44 2017 GMT Subject: countryName = US stateOrProvinceName = Pennsylvania localityName = locality organizationName = Parents organizationalUnitName = Security commonName = gatesentry.domain.lan emailAddress = [email protected] X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, S/MIME Netscape Comment: OpenSSL Generated Client Certificate X509v3 Subject Key Identifier: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX X509v3 Authority Key Identifier: keyid:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection Certificate is to be certified until Jul 2 10:36:44 2017 GMT (375 days) Sign the certificate? [y/n]: y failed to update database TXT_DB error number 2 

I don't understand why I am getting the TXT_DB error number 2 message when I am running the command as root (on another machine of course).

According to the tutorial, I should be able to change the Common Name during this process.

3
  • Do you have additional logs? Add to the post the user that you are using to do this. Commented Jun 22, 2016 at 10:47
  • @RuiFRibeiro root. Commented Jun 22, 2016 at 10:48
  • @RuiFRibeiro Logs? I can't get logs until I can access the proxy. And I need a client certificate for that. Commented Jun 22, 2016 at 10:49

2 Answers 2

2

TXT_DB error number 2 means DB_ERROR_INDEX_CLASH.

You've tried to submit a certificate into the OpenSSL CA database with the same index twice.

The cause of this is usually submitting a certificate to the database that contains the same Serial Number or same Common Name. For the latter, check for the unique_subject option in the intermediate/openssl.conf file, which you can read about in man ca.

The Common Name for a client certificate can be anything - your name, for example.

The Common Name will be specified in the intermediate/openssl.conf file. It can be configured to either prompt for values or read values from the config file. This is controlled by the prompt option, which you can read about in man req.

7
  • Surely, you can't have checked my answer, created a certificate, tested it and come back here to mark this as correct within 1 minute? :-) Commented Jun 22, 2016 at 12:04
  • Okay I'll come back when I've actually done it. But I'm pretty confident that you're right having read the tutorial where it stated that this was the case...I just didn't understand why I wasn't prompted for the values... Commented Jun 22, 2016 at 12:04
  • Error Loading extension in section stackoverflow.com/a/26078472/18149 Commented Jun 22, 2016 at 15:00
  • Error Loading extension in section usr-crt XXXXXXXXXX:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c335:group=CA_default name=email_in_dn Seems similar to this: stackoverflow.com/a/26078472/18149 Could this be coming from an upstream defaults file (by upstream I mean that it comes with the default openssl installation for my distro) I tried setting the unique_subject value to no, since the man page said the default was yes Does this have something to do with subjectNameAlt? if this should go in a separate question let me know Commented Jun 22, 2016 at 15:13
  • Did you follow the suggestions in that answer? Commented Jun 22, 2016 at 18:31
2

According to the tutorial, I should be able to change the Common Name during this process

That tutorial tells you to generate a new key with openssl genrsa AND new CSR with openssl req -new AND create the cert from the CSR with openssl ca. (Although like too many people it wrongly says a cert is created by 'sign[ing] the CSR'. The CA does not sign the CSR. The CA signs the cert, which is creates partly based on the CSR, but is different from the CSR. /rant)

When you generate a new CSR you specify the subject name, including but not limited to the Common Name, which as it says must differ from the CA certs above it, and should differ from other EE certs to avoid confusion.

openssl ca can actually override the subject name for an issued cert (the whole name, not Common Name individually), but this will lead to certs with different names for the same key which is at best unnecessarily confusing and typically less secure (although you don't care about that part, others do, so it isn't made easy).

Error Loading extension in section usr-crt
... no value ... name=email_in_dn
Could this be coming from an upstream defaults file ...

Not directly. openssl ca -config xxx uses xxx, and only xxx, as its config file. If your file is derived from upstream, the section name you want is usr_cert as you have apparently discovered, but you don't need to specify usr_cert because it's the default. The error message about email_in_dn is just leftover in the error stack and the only real error was usr-crt; once you fix that -noemailDN isn't needed although you may want it anyway.

Does this have something to do with subjectNameAlt?

Assuming you mean unique_subject, no. subjectAltName (not subjectNameAlt) aka SAN is a common extension which specifies alternate names for the subject, but unique_subject relates only the basic Subject field not any SAN.

client-side certificate to install in a browser that will be accessing the internet through the proxy

To be clear, a client cert like this is only useful in authenticating yourself to the proxy. You cannot use a cert in the client/browser to authenticate to something on the Internet through ANY HTTPS MitM, and you cannot use a client cert you issue yourself to authenticate to anybody else's system(s) on the Internet.

4
  • "To be clear, a client cert like this is only useful in authenticating yourself to the proxy. You cannot use a cert in the client/browser to authenticate to something on the Internet through ANY HTTPS MitM, and you cannot use a client cert you issue yourself to authenticate to anybody else's system(s) on the Internet." Commented Jun 23, 2016 at 15:40
  • My intent here was to create an https MitM for restricting the hours / sites that my children can access on the internet via Squid 3.3.8 and Dansguardian using a project called GateSentry (abdullahirfan.com/my-projects/gatesentry), so what sorts of certificates do I need to do that? The project itself comes with certificates but I can't trust them, so I'm trying to replace them. I was under the impression that I could self-sign a certificate for that very use. Commented Jun 23, 2016 at 15:41
  • This is why I am under that impression: unix.stackexchange.com/questions/289706/… Commented Jun 23, 2016 at 15:44
  • 1
    @leeand00 The answer on #289706 correctly says an SSL/TLS interceptor like squid+bump must have a CA key and cert, which you should generate yourself so no one else knows the key, and the CA cert (not key) must be installed as a CA cert on your browsers/clients. It does NOT say a client key&cert, which is useless here. This corresponds to only 'root key' and 'root certificate' steps of jamielinux.com/docs/openssl-certificate-authority/… -- no files&dirs for openssl issue (squid does that), no intermediate, no servers and clients. Commented Jun 23, 2016 at 21:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.