OpenSSL For HP NonStop S Series
Can anyone point me to documentation for OpenSSL Installations and Requirements on an HP NonStop (Tandem) S Series system and know if there is a pre-compiled Installation version for HP NonStop avialable. Thanks and regards, -Ken Kenneth Vollmer Sr Software Engineer Support and Development Tel: +1-609-583-9831 Beep: +1-877-327-6099 Fax: +1-609-583-3419 kenneth.voll...@ca.com mailto:kenneth.voll...@ca.com http://www.ca.com/ image001.gif
[FWD] An error appears when run ./CA.sh -sign
Forwarded to openssl-users for public discussion. Best regards, Lutz - Forwarded message from fastrunn...@sina.com - Date: Fri, 12 Dec 2008 14:20:21 +0800 From: fastrunn...@sina.com To: r...@openssl.org Subject: An error appears when run ./CA.sh -sign 1??The env is solaris9+openssl0.9.8i 2??The error message is below: Using configuration from /usr/local/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Error reading certificate request in newreq.pem 29809:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:746: Signed certificate is in newcert.pem 3??The CSR File is newreq.pem??it's content is below?? -BEGIN NEW CERTIFICATE REQUEST- MIIBnjCCAQcCAQAwXjELMAkGA1UEBhMCQ04xCzAJBgNVBAgTAmJqMQswCQYDVQQH EwJiajENMAsGA1UEChMEbWRjbDEMMAoGA1UECxMDbWdzMRgwFgYDVQQDEw9iam1v Y2hhLWh1YW5nd3AwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKrc553GG7Zr MwF4ZMpHFuKOQIt7f1XGLa0Cb2EFt+bAe5iXwg+bI9qOOy3p4UA7SRddzU8cCw5E miU076PI9eT2UsA1xwOxCJKAgYLQAjA04cgPzZ5w3EmvBYnxkawG+8PK5IvX2Voj JN+zV56BVMcEYLensOXv/lvdfIVZ3IADAgMBAAGgADANBgkqhkiG9w0BAQQFAAOB gQBR04JMtcpHZHEB+DlMiHS/466mvExHxVU6NuEmxdkXLhwpbjAqFBPDuWIahgv+ tv59ZhkpNQEcXr0YUKcfpx8g/8dw7MCbsg1gMHPkzQkhOLFJZBnJX7XuasR7HD63 8P1oYSNMXAuFttUt46z7iK1wBE3sq/u11MUljR0oBHukSw== -END NEW CERTIFICATE REQUEST- --- ??(http://space.sina.com.cn/ ) - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openSSL : digest command (md5) to crypto driver
On Fri December 12 2008, Madhusudan Bhat wrote: Hi Geoff, I appreciate your reply. Currently, I dont have any engine supported at the openssl side. I have crypto driver at the kernel side, which registered with the kernel for the hashing and encryption algos. From the openssl, when I issue enc or dgst commands, I dont give engine parameter. Basically, I dont set any engine. With my understanding, openssl will pass the command to kernel, kernel will search the first available registered crypto driver which is capable of handling requested operation and submit the request to that crypto driver. Above things working fine for all encryption and decryption commands. But for hashing (dgst command) kernel is not getting the proper request from the openssl with mac operation set. Any reason, why openssl dont pass the only hashing commands to kernel when no engines are mentioned/set? is there any way I can configure openssl to pass any request to kernel with out looking for any engines and also with out passing it to hadle it in software? Depends on the hardware - if you are running VIA processors, the hash engine is just a pair of instructions in the repeat string op family. No kernel involvement required. Mike thanks, MB. On Fri, Dec 12, 2008 at 2:09 AM, Geoff Thorpe ge...@geoffthorpe.net wrote: On Thursday 11 December 2008 12:44:24 Madhusudan Bhat wrote: Hi All, I am having a issue when using digest command from openssl. When I issue digest command md5 from openssl, kernel side it will never receive IOCTL - CIOCGSESSION with sop-mac getting set, also it wont receive IOCTL - CIOCCRYPT with mac operation set. Tho, crypto driver which I have written registered new session, free session, process functions for CRYPTO_MD5, CRYPTO_MD5_HMAC. But when I issue des/3des/aes enc commands from openssl, open crypto device at the kernel side receives proper IOCTL and calls my crypto driver with new session and process functions with sop-cipher and other fields related to cipher get set. Is there anything I might be missing in my driver or is there anything which I have to enable to receive any digest commands? BTW, I dont have any engine supported, so I dont use engine params while issueing command from openssl. My guess is that you're initialising your engine too late - your engine will only become the default for crypto algorithms/modes that it supports and that *haven't been used yet*. When something tries to use md5 for the first time, a default md5 implementation will be chosen and cached. You probably loaded your engine early enough to be there before anyone needed des/3des/aes, but after someone had already started using md5. Specifically, I'm guessing that randomness gathering is your problem. The random code uses hashes extensively, and if that kicks in before you register your engine's md5 implementation, then the default s/w implementation has already become the live default. Try building your openssl libraries with -DENGINE_TABLE_DEBUG and add a big printf() just before you load your engine. If there is engine logging related to md5 that occurs before you load your engine, that's the problem. Another thing to try is to call ENGINE_set_default() on your engine once it's loaded - your MD5 code after that should use your engine, even if the randomness stuff won't. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ 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
openssl certification chain
Dear all I'm trying to program a small pki for different user groups. Therefore I need to put the certification chain into the pkcs12-File. Is there any possibility to do by using php 5.2? Best regards Norman Sydow
TR: certificate verification with sha256 and squid
Hi all, I am setting up a CA and a reverse proxy https with Squid filtering access to the backend web site. I compiled from source Openssl 0.9.8i on the CA and Squid 2.7 (or 3) servers. I manage to verify the sha256 protected certificate on both computers using : openssl verify -CAFile /root/CA/cacert.pem -verbose /root/72571934AA.pem /root/72571934AA.pem: OK However when Squid checks client certificate it gives an error in log files : SSL unknown certificate error 7 in /C=FR/O=/OU=Users/CN=72571934AA clientNegotiateSSL: Error negotiating SSL connection on FD 11:error : 0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown mesage digest algorithm (1/-1) So I think Squid doesn't understand the sha256 message digest so it cannot verify the certificate ? When I enter the command : openssl list-message-digest-commands : md2 md4 md5 rmd160 sha sha1 There's no sha256 but I don't know if this is normal ? (sha256 would be in sha entry ?) when I do openssl speed I see a sha256 speed calculation. I tried with multiple client browser (linux and windows) that should handle sha256 (debian unstable and Windows XP SP3) I tested multiple versions of Squid and Openssl and the error still show up. I posted a mail on the Squid mailing list and they asked if I had compiled Squid with Openssl support. I did and I don't know where the problem is. I could use sha1 but the CA will be more secure with sha256, as it is designed to last until 2030 :) Could someone give me a hint as I am lost ? Thanks Raphael BUQUET
Re: TR: certificate verification with sha256 and squid
On Fri, Dec 12, 2008, Raphael wrote: Hi all, I am setting up a CA and a reverse proxy https with Squid filtering access to the backend web site. I compiled from source Openssl 0.9.8i on the CA and Squid 2.7 (or 3) servers. I manage to verify the sha256 protected certificate on both computers using : openssl verify -CAFile /root/CA/cacert.pem -verbose /root/72571934AA.pem /root/72571934AA.pem: OK However when Squid checks client certificate it gives an error in log files : SSL unknown certificate error 7 in /C=FR/O=/OU=Users/CN=72571934AA clientNegotiateSSL: Error negotiating SSL connection on FD 11:error : 0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown mesage digest algorithm (1/-1) So I think Squid doesn't understand the sha256 message digest so it cannot verify the certificate ? Possibly it is calling SSL_library_init() which doesn't add a complete set of digests. OpenSSL_add_all_algorithms() should be called as well. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[no subject]
__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openSSL : digest command (md5) to crypto driver
On Friday 12 December 2008 01:07:04 Madhusudan Bhat wrote: Hi Geoff, I appreciate your reply. Currently, I dont have any engine supported at the openssl side. I have crypto driver at the kernel side, which registered with the kernel for the hashing and encryption algos. From the openssl, when I issue enc or dgst commands, I dont give engine parameter. Basically, I dont set any engine. With my understanding, openssl will pass the command to kernel, kernel will search the first available registered crypto driver which is capable of handling requested operation and submit the request to that crypto driver. If no engine is set up, then openssl will use its own software implementations to perform all crypto operations. If openssl is passing anything to hardware via the kernel, that's because an engine has been setup. You are probably using the cryptodev engine without realising it. What is your platform, and what is your application? In particular, does it call ENGINE_load_builtin_engines() at all? Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
common name charset question
hello, i've a problem/question is it possible to use charset like croatian or russian in the common name field to generate a /pkcs12/ certificate? charset like iso-8859-2, windows-1250 so non standard ascii charset. And if is it possible how i can do it? tahnk's a lot -- ** Ing. Matteo Cazzador NetLite Snc di Gagliardi A. Cazzador M. Email: mat...@netlite.it Web: http://www.netlite.it ** __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: common name charset question
On Fri, Dec 12, 2008 at 09:57:34PM +0100, Matteo Cazzador wrote: is it possible to use charset like croatian or russian in the common name field to generate a /pkcs12/ certificate? Yes, you can use UTF8, which includes Russian and Croatian characters. charset like iso-8859-2, windows-1250 so non standard ascii charset. And if is it possible how i can do it? You can't use language-specific encodings, you can only use ASCII or UTF8, or in some cases T61 (similar to iso-8859-1) is also usable. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: common name charset question
Victor Duchovni ha scritto: On Fri, Dec 12, 2008 at 09:57:34PM +0100, Matteo Cazzador wrote: is it possible to use charset like croatian or russian in the common name field to generate a /pkcs12/ certificate? Yes, you can use UTF8, which includes Russian and Croatian characters. charset like iso-8859-2, windows-1250 so non standard ascii charset. And if is it possible how i can do it? You can't use language-specific encodings, you can only use ASCII or UTF8, or in some cases T61 (similar to iso-8859-1) is also usable. thank's a lot , excuse me for my insistence and my orrible english, so i can only use utf8 encoding common name for est people?. I must generate psk12 for croatian people that send me particular charset (surname and name) and in must put it in cn for p12 creation. For me the charset problematic is relative because i come from italy and i use iso-8859-15. So is the first time i try to solve it. Ultimate consideration, if i use utf8, who use his p12 certificate, see correct charset ? thank's a lot -- ** Ing. Matteo Cazzador NetLite Snc di Gagliardi A. Cazzador M. Email: mat...@netlite.it Web: http://www.netlite.it ** __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: common name charset question
On Fri, Dec 12, 2008 at 10:24:46PM +0100, Matteo Cazzador wrote: Victor Duchovni ha scritto: On Fri, Dec 12, 2008 at 09:57:34PM +0100, Matteo Cazzador wrote: is it possible to use charset like croatian or russian in the common name field to generate a /pkcs12/ certificate? Yes, you can use UTF8, which includes Russian and Croatian characters. charset like iso-8859-2, windows-1250 so non standard ascii charset. And if is it possible how i can do it? You can't use language-specific encodings, you can only use ASCII or UTF8, or in some cases T61 (similar to iso-8859-1) is also usable. thank's a lot , excuse me for my insistence and my orrible english, so i can only use utf8 encoding common name for est people?. I must generate psk12 for croatian people that send me particular charset (surname and name) and in must put it in cn for p12 creation. For me the charset problematic is relative because i come from italy and i use iso-8859-15. So is the first time i try to solve it. Ultimate consideration, if i use utf8, who use his p12 certificate, see correct charset ? Correctly implemented certificate parsers will display UTF8 encodings to the user in a way that the user can understand. The code-points are logically the same regardless of the encoding. UTF-8 is the only non Latin encoding supported with X.509 DirectoryNames (e.g. CN). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: common name charset question
Victor Duchovni ha scritto: On Fri, Dec 12, 2008 at 10:24:46PM +0100, Matteo Cazzador wrote: Victor Duchovni ha scritto: On Fri, Dec 12, 2008 at 09:57:34PM +0100, Matteo Cazzador wrote: is it possible to use charset like croatian or russian in the common name field to generate a /pkcs12/ certificate? Yes, you can use UTF8, which includes Russian and Croatian characters. charset like iso-8859-2, windows-1250 so non standard ascii charset. And if is it possible how i can do it? You can't use language-specific encodings, you can only use ASCII or UTF8, or in some cases T61 (similar to iso-8859-1) is also usable. thank's a lot , excuse me for my insistence and my orrible english, so i can only use utf8 encoding common name for est people?. I must generate psk12 for croatian people that send me particular charset (surname and name) and in must put it in cn for p12 creation. For me the charset problematic is relative because i come from italy and i use iso-8859-15. So is the first time i try to solve it. Ultimate consideration, if i use utf8, who use his p12 certificate, see correct charset ? Correctly implemented certificate parsers will display UTF8 encodings to the user in a way that the user can understand. The code-points are logically the same regardless of the encoding. UTF-8 is the only non Latin encoding supported with X.509 DirectoryNames (e.g. CN). It's clear Thank's a lot ! -- ** Ing. Matteo Cazzador NetLite Snc di Gagliardi A. Cazzador M. Email: mat...@netlite.it Web: http://www.netlite.it ** __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: common name charset question
On Fri, Dec 12, 2008 at 10:46:20PM +0100, Matteo Cazzador wrote: Correctly implemented certificate parsers will display UTF8 encodings to the user in a way that the user can understand. The code-points are logically the same regardless of the encoding. UTF-8 is the only non Latin encoding supported with X.509 DirectoryNames (e.g. CN). It's clear Thank's a lot ! One final subtle point, the software that creates the certificate has to ensure that the DirectoryString is labeled as UTF8 String. And I neglected to mention that you can also use Unicode. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OWASP Hartford: February 2009 (Open Web Application Security Project)
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-05.00) Eastern Time (US Canada) X-MICROSOFT-CDO-TZID:10 BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20081125T200509Z DTSTART;TZID=(GMT-05.00) Eastern Time (US Canada):20090210T17 SUMMARY:OWASP Hartford: February 2009 (Open Web Application Security Projec t) UID:04008200E00074C5B7101A82E0086015A2316121C901000 010008755599A2D01DB488364749052F323A6 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=openssl-u s...@openssl.org:MAILTO:openssl-users@openssl.org ORGANIZER;CN=James McGovern:MAILTO:ja...@architectbook.com LOCATION:The Hartford\, Tower Building: Atrium Conference Room DTEND;TZID=(GMT-05.00) Eastern Time (US Canada):20090210T19 DESCRIPTION:\NThe Open Web Application Security Project (OWASP) is a worldw ide free and open community focused on improving the security of applicati on software. Our mission is to make application security visible\, so th at people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our ma terials are available under a free and open software license. \N\NThe agen da for this meeting is posted at: http://www.owasp.org/index.php/Hartford\ N\NTo receive future invites\, please subscribe to our mailing list at: ht tps://lists.owasp.org/mailman/listinfo/owasp-hartford\N SEQUENCE:1 PRIORITY:5 CLASS:Company-Confidential CREATED:20081212T200509Z LAST-MODIFIED:20081212T200509Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:OOF X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-REPLYTIME:20081201T163100Z X-MICROSOFT-CDO-INTENDEDSTATUS:OOF X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1986226216 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20081212T174513Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20081125T200509Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-P3DT00H00M00S END:VALARM END:VEVENT END:VCALENDAR
Accepted: OWASP Hartford: February 2009 (Open Web Application Security Project)
BEGIN:VCALENDAR METHOD:REPLY PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-08.00) Pacific Time (US Canada)/Tijuana X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20081125T200509Z DTSTART;TZID=(GMT-08.00) Pacific Time (US Canada)/Tijuana:20090210T1400 00 SUMMARY:Accepted: OWASP Hartford: February 2009 (Open Web Application Secur ity Project) UID:04008200E00074C5B7101A82E0086015A2316121C901000 010008755599A2D01DB488364749052F323A6 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE;CN=Buicliu, Ion VSA:EX:MAILTO:ion.buic...@gov.bc.ca ORGANIZER:MAILTO:openssl-users@openssl.org LOCATION:The Hartford\, Tower Building: Atrium Conference Room DTEND;TZID=(GMT-08.00) Pacific Time (US Canada)/Tijuana:20090210T16 SEQUENCE:1 PRIORITY:5 CLASS:Company-Confidential CREATED:20081212T222442Z LAST-MODIFIED:20081212T222442Z STATUS:TENTATIVE TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-REPLYTIME:20081212T222442Z X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1986226216 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20081212T222442Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20081125T200509Z END:VEVENT END:VCALENDAR
RE: Accepted: OWASP Hartford: February 2009 (Open Web Application Security Project)
I am very sorry for pressing Accept without looking carefully to what was in front of me. Please cancel - I will not be able to attend. Thank you. Ion Buicliu Systems Integration Specialist BC Vital Statistics Agency Health Sector IM/IT Division Voice Mail: (250) 952-2410 Please consider the environment before printing this email. Unless otherwise agreed expressly in writing by the author, this communication is to be treated as confidential and the information in it (or attached to it) may not be used or disclosed except for the purpose for which it has been sent or as determined by FOIPPA requirements and procedures. This message is intended only for the use of the person(s) to whom it is addressed. Any distribution, copying or use by anyone else is strictly prohibited. If you have received this e-mail in error, please telephone the sender immediately and destroy this e-mail. _ From: Buicliu, Ion VSA:EX [mailto:ion.buic...@gov.bc.ca] Sent: Fri, December 12, 2008 2:25 PM To: openssl-users@openssl.org Subject: Accepted: OWASP Hartford: February 2009 (Open Web Application Security Project) When: Tue, February 10, 2009 2:00 PM-4:00 PM (GMT-08:00) Pacific Time (US Canada). Where:The Hartford, Tower Building: Atrium Conference Room Sensitivity: Confidential
Accepted: OWASP Hartford: February 2009 (Open Web Application Security Project)
BEGIN:VCALENDAR METHOD:REPLY PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VEVENT DTSTAMP:20081125T200509Z DTSTART:20090210T22Z SUMMARY:Accepted: OWASP Hartford: February 2009 (Open Web Application Secur ity Project) UID:04008200E00074C5B7101A82E0086015A2316121C901000 010008755599A2D01DB488364749052F323A6 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE;CN=Jannette Mich ele-MGIA0360:MAILTO:mjanne...@motorola.com ORGANIZER:MAILTO:openssl-users@openssl.org LOCATION:The Hartford\, Tower Building: Atrium Conference Room DTEND:20090211T00Z SEQUENCE:1 PRIORITY:5 CLASS:Company-Confidential CREATED:20081212T223656Z LAST-MODIFIED:20081212T223657Z STATUS:TENTATIVE TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-REPLYTIME:20081212T223655Z X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1986226216 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20081212T223655Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20081125T200509Z END:VEVENT END:VCALENDAR
Using fipsld on Unix links.
Hello, I'm having a problem with the fipsld script when trying to line the fips-1.2 libraries to my programs. This is on a Sun UNIX system. My problem is during the fingerprint validation. The reference sha1 files, built at the time of the build of the rest of the library have the filename with no path in them. When I'm building my executables, the output from the fips_standalone_sha1 executable includes the relative path for the file being fingerprinted, making the result not match the reference file. Can I modify the fipsld file and maintain fips validation? Can I modify the sha1 output files from the build to have the correct relative path and maintain fips validation? Does anyone have any other suggestions? Thanks, Gerald Collins __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Accettato: OWASP Hartford: February 2009 (Open Web Application Security Project)
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REPLY X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;PARTSTAT=ACCEPTED:mailto:marco.somme...@gmail.com CLASS:PUBLIC CREATED:20081213T033221Z DTEND:20090211T00Z DTSTAMP:20081213T033221Z DTSTART:20090210T22Z LAST-MODIFIED:20081213T033221Z LOCATION:The Hartford\, Tower Building: Atrium Conference Room PRIORITY:5 SEQUENCE:1 SUMMARY:Accettato: OWASP Hartford: February 2009 (Open Web Application Secu rity Project) TRANSP:OPAQUE UID:04008200E00074C5B7101A82E0086015A2316121C901000 010008755599A2D01DB488364749052F323A6 X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-IMPORTANCE:1 X-MS-OLK-AUTOFILLLOCATION:FALSE X-MS-OLK-CONFTYPE:0 END:VEVENT END:VCALENDAR __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Declined: OWASP Hartford: February 2009 (Open Web Application Security Project)
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REPLY X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;PARTSTAT=DECLINED:mailto:jjao...@gmail.com CLASS:PUBLIC CREATED:20081213T035112Z DESCRIPTION:\n DTEND:20090211T00Z DTSTAMP:20081213T035113Z DTSTART:20090210T22Z LAST-MODIFIED:20081213T035116Z LOCATION:The Hartford\, Tower Building: Atrium Conference Room PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:Declined: OWASP Hartford: February 2009 (Open Web Ap plication Security Project) TRANSP:OPAQUE UID:04008200E00074C5B7101A82E0086015A2316121C901000 010008755599A2D01DB488364749052F323A6 X-ALT-DESC;FMTTYPE=text/html:!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//E N\nHTML\nHEAD\nMETA NAME=Generator CONTENT=MS Exchange Server ve rsion 08.00.0681.000\nTITLE/TITLE\n/HEAD\nBODY\n!-- Converted f rom text/rtf format --\n\nP DIR=LTRSPAN LANG=en-us/SPAN/P\n\n/ BODY\n/HTML X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-IMPORTANCE:1 X-MS-OLK-AUTOFILLLOCATION:FALSE X-MS-OLK-CONFTYPE:0 END:VEVENT END:VCALENDAR __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
