[openssl-users] OpenSSL LogoType extension ASN1 encoding
Hello everyone, I am trying to add the logotype extension to certificates under a private CA I am taking care of. The CA is built using OpenVPN's Easy-RSA 3 tool, though I think that doesn't matter in this situation. I have some questions regarding this matter. Before digging into details I will tell you the problem I want to solve. I have multiple different logos. Searching the Internet I have found an E-Mail from November 2010 [1]. Based on that information I have reached to the following snippet of configuration: cat ./exts # Logos 1.3.6.1.5.5.7.1.12 = ASN1:SEQUENCE:logotype_ext [logotype_ext] issuerLogo=EXPLICIT:1,IMPLICIT:1,SEQUENCE:logotype_indirect [logotype_indirect] refStructHash=SEQWRAP,SEQUENCE:HashAlgAndValue refStructURI=SEQWRAP,SEQUENCE:IA5String:http://logos.example.org/logo0.png [HashAlgAndValue] hashAlg=SEQUENCE:logo_algid hashValue=FORMAT:HEX,OCTETSTRING:9c2c672338e1a6615ccfa78097c0ed8681e3335d [logo_algid] capabilityID = OID:sha1 parameter = NULL I receive the following error when I try to issue a certificate using openssl. The same when I use the easyrsa wrapper script. $ openssl ca -in 10.req -out 10.crt -config openssl-1.0.cnf -extfile exts -days 3650 -batch Using configuration from openssl-1.0.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'DE' organizationName :ASN.1 12:'10' organizationalUnitName:ASN.1 12:'Cortex AG Trust Network' organizationalUnitName:ASN.1 12:'(c) Cortex AG - For authorized use only!' commonName:ASN.1 12:'Cortex AG Root Certification Authority' ERROR: adding extensions in section default 6987:error:22074074:X509 V3 routines:V3_GENERIC_EXTENSION:extension value error:/SourceCache/OpenSSL098/OpenSSL098-52/src/crypto/x509v3/v3_conf.c:282:value=SEQUENCE:logotype_ext I have tried changing SEQWRAP with SEQUENCE and also variations I have found in [1]. None of them worked. Can someone please tell me what am I doing wrong. Also I have a couple of logos I want to add to the certificate. How would I encode that in openssl.cnf? [1]: http://openssl.6102.n7.nabble.com/Logotype-encoding-td15882.html Thank you, Valentin Bud ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Web site: Send to Majordomo broken
On Wed, Jan 16, 2013 at 02:02:23PM +, Bruce Cran wrote: On http://www.openssl.org/support/community.html the mailing list subscription feature is broken - clicking Send to Majordomo just displays the majordomo.cgi script. -- Bruce Cran __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Hello World, I was going to email the list to let you know about this and when I've entered the mail I saw your email Bruce. I can double this: Send to Majordomo is broken. Valentin Bud __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate Authority: deamon and or iptables?
Greetings Earthling, I am not much of an expert on the matter of CAs but I jump in with some knowledge I have until now. Inline. On Tue, Oct 2, 2012 at 10:42 AM, Darod Zyree darodzy...@gmail.com wrote: Greetings, I am confused about something and I could not find the information I was looking for. We are planning to set up our own Certificate Authority server on our internal network. After having read several how-to’s, and other documentation on how to set up such a server, we are left with two questions: 1) Which daemon/service needs to be running for a CA server to deal with incoming certificate checks from clients If you plan to go the CRL route you need a web server (go nginx for your own sake) that serves the CRL at the appointed CRL URI you've set up in your Certificates. You'd also need an automated, or not, way to generate CRLs before they expire. If you plan to disseminate certificates using LDAP you'd need a LDAP server up and running. OpenLDAP is the first choice that comes to mind. Especially with the latest improvements. Search for OpenLDAP MDB if you want to learn more. And there is OCSP [1], an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. For this you need a daemon that implements this protocol. I don't know many things about it, never have studied it. I do know that EJBCA [2] have an OCSP implementation. There may be others. You also need a set of scripts to ease your life. Scripts for generating, revoking certificates and other CA operations. Or you can go the EJBCA route for a full blown solution. Might be overkill in your case. [1]: http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol [2]: http://www.ejbca.org/installation-ocsp.html And 2) Which firewall ports need to be configured for this? LDAP works on 636 (SSL), 389. Web service on 80. OCSP uses HTTP as transport, you can choose 80 or another port number for that. Cheers and Goodwill, v __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
I want to implement a CA using openssl and some (basic) bash scripting. I try to understand and conform with the standards. So I have started by reading RFC5280 [1]. I want to write a CPS and link to it from the CA using certificatePolicies cPSuri qualifier. First thing I did was to generate an UUID OID following ITU-T instructions [2]. Afterwards I added to openssl.cnf the following: = = = = = = = = company_root_oid = 2.25.c8b2e2a0094b11e2936a0002a5d5c51b [ v3_ca ] certificatePolicies = ia5string,@company_ca_policy [ company_ca_policy ] policyIdentifier = 2.25.c8b2e2a0094b11e2936a0002a5d5c51b.2.5.29.32.1 CPS.1 = http://pki.edoxx.net/cps/; userNotice.1 = @edoxx_ca_notice [ company_ca_notice ] explicitText= Compnay Primary CA thrives to conform with latest PKIX RFCs. The Company Trust Network is operated as stated in the CPS: http://pki.company.net/cps/. We recommend you read it before trusting us. = = = = = = = = I feel compeled to tell you that company_ca_policy and company_ca_notice appear before v3_ca. I don't really know if the order matters. I have done this following the example provided on x509_config(5) [3] manual page. Next step was to generate the CA. wiz:CA/ (master???) $ openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/edoxx.ca.key -out certs/edoxx.ca.pem -config openssl.cnf problem creating object edoxx_root_oid=2.25.c8b2e2a0094b11e2936a0002a5d5c51b 28675:error:0D064082:asn1 encoding routines:a2d_ASN1_OBJECT:invalid digit:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/asn1/a_object.c:139: I know I'm doing something wrong but I don't know what. Can you please shed some light? [1]: http://tools.ietf.org/html/rfc5280 [2]: http://www.itu.int/ITU-T/asn1/uuid.html#registration [3]: http://www.openssl.org/docs/apps/x509v3_config.html Thanks. Cheers and Goodwill, v __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
Hello Erwann, On Fri, Sep 28, 2012 at 02:53:35PM +0200, Erwann Abalea wrote: Strange, my previous answer was sent empty, and every try results in an empty mail stored in my postponed folder... Anyway. Use decimal numbers for an OID. Yours will be 2.25.266774424501754920443129542379924997403 How did you transform the number from hex to decimal? I have been looking to do this for an hour now to no avail. Thanks for giving me the number. Still it doesn't work. Another error now. But first, the changes I have done are as follows: openssl.cnf === # This is at the beginning of the file company_root_oid = 2.25.266774424501754920443129542379924997403 [ company_ca_policy ] policyIdentifier = company_root_oid.2.5.29.32.1 [ company_v3_ca ] certificatePolicies = ia5org,@company_ca_policy === The error is the following: wiz:CA/ (master) $ openssl req -new -x509 -days 3650 -extensions company_v3_ca -keyout private/company.ca.key -out certs/company.ca.pem -config openssl.cnf Error Loading extension section v3_ca 6198:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/asn1/a_object.c:109: 6198:error:2208306E:X509 V3 routines:POLICY_SECTION:invalid object identifier:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/x509v3/v3_cpols.c:211:section:company_ca_policy,name:policyIdentifier,value:company_root_oid.2.5.29.32.1 6198:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/x509v3/v3_conf.c:93:name=certificatePolicies, value=ia5org,company_ca_policy The OpenSSL version, if it matters is: wiz:CA/ (master) $ openssl version OpenSSL 0.9.8r 8 Feb 2011 I don't know what I am doing wrong. PKI is a vast topic with a lot of things to grasp. I have to take it slow. I do have one question though. In the link that Ryan Hurst suggested the policyIdentifier is left out. What is the difference between the two? Would I be RFC compliant if I would use a policyIdentifier or none at all or it doesn't matter? I have read somewhere that some applications cannot parse UUIDs. If using a certificate policy without a policyIdentifier would keep me RFC complaint I would choose to do that. I don't want to get in trouble with applications. Acquiring an OID for the company is not possible, at least for now. I guess that would be the most elegant solution. This is my first day with OpenSSL and CA stuff. I have read a good book [1] on the topic, in the past. I have started reading it again plus the RFCs. There is a lot of info to process, uderstand and apply so please bare with me if my questions are rather stupid. [1]: Understanding PKI Concepts, Standards And Deployment Considerations - By: Carlisle Adams; Steve Lloyd Thank you for your patience. Cheers and Goodwill, v And for your policyIdentifier, it should be easier to read if expressed as company_root_oid.2.5.29.32.1. -- Erwann ABALEA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: UUID OID and certificatePolicies routines:a2d_ASN1_OBJECT:invalid digit
Hello Jakob, On Fri, Sep 28, 2012 at 04:20:00PM +0200, Jakob Bohm wrote: Simple really: Indeed. When you know a certain topic and you've studied for a certain time it's really simple. For me, for now, compliant RFC CA is a nebula. I am starting to see the what pieces this puzzle needs and to be able to find documentation so I can study the topic. The OID must be written in decimal, not hexadecimal. Didn't know that before Erwann answered. I guess it's logic for the number to be in decimal since all the others are in decimal, on the OID tree I mean. The reason, I guess is from encoding. Please refer to the ITU-T page you referenced to figure out how the bytes and bits of your UUID map to numeric parts of the OID and then write those out in decimal. Should have looked more carefully on the UUID generation page and read [1]. Some new material to study. Thank you for pointing me in the right direction. Cheers and Goodwill, v __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
