what is range of attime in OpenSSL - c

I need to check the validity of few certificates and am using -attime flag with my OpenSSL command
openssl cms -verify -inform DER *** -attime epochvalue.
I got a doubt here, about the data type of epochvalue, then had a look at the link
https://www.openssl.org/docs/man1.1.1/man1/openssl-s_server.html
in which it is mentioned as [-attime intmax]. I believe intmax mentioned here same as INT_MAX of limits.h
If attime range is only till INT_MAX, which when converts to epoch will be 2147483647 and is nothing but till Tuesday, January 19, 2038 3:14:07, how will the certificates after this date will be validated?

Related

Why the modified source code of the openssl does not work

I tried to change the source code of the openssl, e.g. dhparam.c
I Added the printf just like below:
printf("This is in dhparam\n");
BIO_printf(bio_err,
"Generating DH parameters, %d bit long safe prime, generator %d\n", num, g)
After compile and install, I run the openssl command, the result is:
openssl dhparam -out dh.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
...
There is no message I added is shown. So does any one know the reason?
Thanks.

What are bag attributes and how can i generate them?

while converting some certificates from keystore to openssl/pem I noticed for the first time that there are "Bag Attributes" prepended to the certs.
The look like this:
Bag Attributes
friendlyName: CN=PositiveSSL CA,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
subject=/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
Do they serve any function?
I noticed that I like them because they make my chain-files (a concatenation of certificates) more clear. Sadly the ca certs I download don't have them.
So how do I generate them?
To be exact, you apparently mean converting (or just reading) with the openssl pkcs12 (import) utility a PKCS#12 file, which can be supported by Java as a keystore but was not the default (update) until Java9 in 2017. PKCS#12 was designed and normally is used for a privatekey and the cert(s) (usually multiple) for that key, although the format is flexible enough to allow lone cert(s). OpenSSL commandline pkcs12 -export requires a privatekey, although it will add "extra" certs, and a program calling the API can apparently do no privatekey. In my experience, Java didn't support lone cert(s) in PKCS#12 before version 8, and in my 8 and 9 has two attributes: pkcs9.friendlyName and 2.16.840.1.113894.746875.1.1 which is apparently an Oracle-defined trustedKeyUsage. Most lone certs are not stored, or downloaded, as PKCS#12.
PKCS#12 is defined in terms of several (slightly different) "bag" structures that contain various things, primarily privatekeys and certs with optional attributes attached that are unsurprisingly called "bag attributes"; your case (apparently) has only cert(s). These attributes follow the now-conventional structure of an arbitrary number of pairs of OID plus value depending on the OID. Note in your display only friendlyName is a bag attribute, indicated because it is indented under the heading.
The subject= and issuer= lines are fields from the cert itself which the openssl pkcs12 (import) utility extracts and prints for convenience. If that is sufficient, you can display them for any cert with the x509 utility; in particular if you want to have them before the PEM-encoded cert "blob" in the way pkcs12 output does, use openssl x509 -in infile -subject -issuer -out outfile. This does one cert, so if you have a chain in a PEM file you need to split it apart and do each cert separately, and possibly combine again afterwards; for example something like
# split into files cert_1, cert_2, etc.
$ awk <chain.pem -va="openssl x509 -subject -issuer >cert_"
'/^-----BEGIN/{b=a (++n);x=1}x{print|b}/^-----END/{close(b);x=0}'
# output entire "bag" to stdout (with blank lines between certs)
$ awk <chain.pem -va="openssl x509 -subject -issuer" \
'/^-----BEGIN/{b=a;x=1}x{print|b}/^-----END/{close(b);x=0;print""}'
As a comparison, openssl s_client -showcerts does something very similar: it outputs subject and issuer with each cert blob from the received chain, labelling them with a level number, "s:" and "i:".

Issue with crypt C API on AIX 7.1

I am writing a password reset utility on AIX (7.1.0.0) and I need to support SMD5, SSHA256, SSHA512 and BLOWFISH password hash algorithms. I have successfully implemented the code for SMD5, SSHA256 and SSHA512. However, for BLOWFISH algorithm the 'crypt' API still returns normal DES hash and not the BLOWFISH hash. I tried different prefixes in salt value - {sblowfish} {sblowfish}08$ {SBLOWFISH} {SBLOWFISH}08$. However, I still don't get blowfish hash. For, AIX 5.3 {sblowfish} prefix in salt value works and I get required hash. However, for AIX 7.1 it doesn't work.
The format for the salt value I am using is as follows -
MD5 - {smd5}<randomly generated 8 characters>$
SHA256 - {ssha256}06$<randomly generated 8 characters>$
SHA512 - {ssha512}06$<randomly generated 8 characters>$
BLOWFISH - {sblowfish}08$<randomly generated 22 characters>$
I then pass the user password and salt value to the 'crypt' API in 'C'.
crypt(password, salt);
For MD5, SHA256 and SHA512 I get the password hash which is compliant to the corresponding algorithm.
However, for BLOWFISH salt, the 'crypt' API rejects the salt and instead returns normal DES hash though i have the blowfish in the system.
Can anybody please help out here? Thanks in advance.

Different encrypted outputs in AES implementations? [duplicate]

I've compiled some AES implementation code from this site, it's supposed to perfrom a 128 bits key encryption. I tested the encryption/decryption programs which work OK together.
However if I encrypt anything with the mentioned code and then try to decrypt it by openssl tool built-in in linux, I just can't get decrypt it, it even logs me the bad magic number error. Same, if I encrypt anything with openssl and try to decrypt with the code won't work. I tried with both cbc ecb.
If they're both implementing AES, shouldn't it work same way?
it looks like the C code is using ECB and does no padding. so try encrypting a message (a multiple) of 16 bytes followed by 16 bytes of value 16 (pkcs#7 padding). or use a message (a multiple) of 16 bytes and --nopad in openssl (more likely to work). also, use aes-128-ecb or whatever it's called.
a block cipher works on "chunks" of text - in this case, it's 16 characters long. so if you don't want to worry about padding you need to give an exact number of chunks.
also, ecb mode (doing each chunk in turn with no extra processing) isn't secure for many uses. see the wikipedia article (look at the penguin photos).
[edit:] [edit 2:]
> echo -n "abcdabcdabcdabcd" > msg
> wc msg
0 1 16 msg
> openssl enc -aes-128-ecb -nopad -in msg -K 0 -S "" -iv ""
[noise]
> openssl enc -aes-128-ecb -nopad -in msg -K 0 -S "" -iv "" | wc
0 1 16
try the above yourself and see if the other code decrypts it (edit 2 sets the key explicitly, and removes IV and salt - not sure what the latter two are for in this case).
[edit 3:]
as far as i can tell, the problem is related to the way that the password is converted to a key. openssl seems to be doing something extra that i can't get rid of unless i specify a key as hex (-K 0). and if i do that, the other program doesn't work (needs a password).
sorry, i'm out of ideas.

secure client/server program in C with OpenSSL

I'm trying to write a secure client/server program in C with OpenSSL.
I've found a code sample at http://www.rtfm.com/openssl-examples/ but I get this error:
server: SSL read problem
client: Certificate doesn't verify
I think the problem is with the certificate generation, but I cannot find it.
Any idea?
Thanks
I downloaded the example and verified the error:
"10 X509_V_ERR_CERT_HAS_EXPIRED: certificate has expired"
With this command:
openssl x509 -in client.pem -noout -text
I got this output:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 258 (0x102)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, O=RTFM, Inc., OU=Widgets Division, CN=Test CA20010517
Validity
Not Before: May 17 16:11:36 2001 GMT
Not After : Mar 6 16:11:36 2004 GMT
Subject: C=US, O=RTFM, Inc., OU=Widgets Division, CN=client
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:87:35:64:a8:36:1e:a6:b1:4c:18:18:67:7b:4d:
84:03:b1:d4:86:d1:aa:3a:41:76:98:8e:4f:bb:f1:
9c:8c:41:e6:54:06:ed:9d:64:58:c6:e3:09:f3:90:
ac:2b:0f:8a:e9:fc:9e:4f:2d:1f:40:77:14:7b:da:
56:fd:01:ab:c4:38:a2:f6:50:31:c9:1a:cb:1c:66:
41:95:c3:f6:f3:65:bc:6b:28:5d:ab:bd:da:59:4a:
f2:8f:d4:e8:55:d4:c3:9d:b3:f5:93:a5:19:b5:81:
c9:95:4a:85:79:bc:b3:8c:a9:58:f3:8c:7a:31:43:
ff:b5:ce:98:f3:33:15:8b:d3
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
24:c9:85:14:79:b6:ff:00:ed:d7:39:fb:39:8a:47:54:3f:8b:
ca:84:dc:ca:e7:9a:9f:cc:39:71:df:5f:e8:9f:27:fc:3e:b7:
0a:1c:ff:27:78:12:7f:bb:a6:bf:a1:1a:c8:93:a1:f7:2d:d4:
93:99:0d:6f:40:92:af:d9:1a:ed:7e:36:95:51:4f:b0:b0:e7:
71:1d:33:0a:62:ec:0a:f0:64:0b:0b:21:40:6c:28:0e:d0:98:
b4:db:77:08:d4:e5:2e:d6:95:9d:b8:7b:28:19:1f:2a:99:ac:
ae:05:7b:0f:89:bb:39:45:92:4a:08:14:80:c2:7e:29:f2:cf:
6e:26
Not After : Mar 6 16:11:36 2004 GMT
shows that was valid until 2004
You have to create a new certificate to use this example.
You can check those sites:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s02.html#cert2-fig
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
http://blog.taragana.com/index.php/archive/openssl-how-to-create-self-signed-certificate/
http://sandbox.rulemaker.net/ngps/m2/howto.ca.html
http://novosial.org/openssl/ca
Get the value returned by SSL_get_verify_result(ssl) and compare it to the list of results in the Diagnostics section of OpenSSL's verify page. This will tell you the exact error.

Resources