[no subject]

https://mta.openssl.org/pipermail/openssl-users/attachments/20211109/b5cd5f1e/attachment-0001.html

[no subject]

[no subject]

[no subject]

[no subject]

Hello I was wondering how to migrate to a provider for Openssl 3.0 an engine for openssl 1.0.2 that was simply defining on an RSA_METHOD structure the method for modular exponentiation for RSA and getting call parameters from RSA_get_ex_data(), in order then to use an hw accelerator. Other methods

[no subject]

Hi #define of BIOerr and BUFerr is deprecated in openssl3.0 # ifndef OPENSSL_NO_DEPRECATED_3_0 #define BIOerr(f, r) ERR_raise_data(ERR_LIB_BIO, (r), NULL) # define BUFerr(f, r) ERR_raise_data(ERR_LIB_BUF, (r), NULL) #endif The BIOerr and BUFerr are used in the code something like below

Re: Parsing subject/issuer strings in X.509

Yeah, agreed, although I'd like the parser to work with the output of "openssl x509 ... -subject", i.e. RFC-4514 format, which is "CN=name, O=Acme Corporation, C=US" ... etc. > On Jul 23, 2021, at 12:57 AM, David von Oheimb wrote: > > What I use is > >

Re: Parsing subject/issuer strings in X.509

>> X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char >> *desc) >> >> Would be good to have such a function as part of the X.509 API. > > Note that the "/"-separated form is not the output format of the issuer or > subject name

Re: Parsing subject/issuer strings in X.509

Yeah, agreed, although I'd like the parser to work with the output of "openssl x509 ... -subject", i.e. RFC-4514 format, which is "CN=name, O=Acme Corporation, C=US" ... etc. > On Jul 23, 2021, at 12:57 AM, David von Oheimb wrote: > > What I use is > >

Re: Parsing subject/issuer strings in X.509

ave such a function as part of the X.509 API. Note that the "/"-separated form is not the output format of the issuer or subject names in X509_NAME_oneline(3), x509(1), ... So a public API for that format may not be a good idea. Perhaps there could be parsers for the "rfc2253", &

Re: Parsing subject/issuer strings in X.509

What I use is     X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc); which is not an official API function but defined in apps/lib/apps.c: /*  * name is expected to be in the format /type0=value0/type1=value1/type2=...  * where + can be used instead of / to form multi-valued RDNs

Re: Parsing subject/issuer strings in X.509

> On 22 Jul 2021, at 9:29 pm, Philip Prindeville > wrote: > > I'm wondering what the function is that takes a string and returns X509_NAME > with the attribute/value pairs of the parsed DN. There is no such function in general, since the are many potential string forms of X.509 names, not all

Parsing subject/issuer strings in X.509

Hi, I'm wondering what the function is that takes a string and returns X509_NAME with the attribute/value pairs of the parsed DN. Thanks, -Philip

[no subject]

Hi, I am building Nginx application with openssl-3.0.0, i have added below code in main function of nginx application to load fips provider, OSSL_PROVIDER *fips; OSSL_PROVIDER *base; fips = OSSL_PROVIDER_load(NULL, "fips"); if (fips == NULL) { printf("Failed to

[no subject]

Hi, How to verify if the application is using fips provider from openssl-3.0.0 ( similar to fips_mode() api in openssl-fips-2.0.16) and does fips provider do run time check and through error if application using non fips ciphers. Regards, Nagarjun

Re: Multi-valued RDN in Subject Alternative Name extension

On Sat, 20 Jun 2020 at 10:21, Michael Ströder wrote: > > On 6/18/20 9:12 AM, Williams, Gareth wrote: > > I can successfully add a multi-value RDN to the Subject of a > > certificate request using the + format in the config file: > > [..] > > However,

Re: Multi-valued RDN in Subject Alternative Name extension

On 6/18/20 9:12 AM, Williams, Gareth wrote: > I can successfully add a multi-value RDN to the Subject of a > certificate request using the + format in the config file: > [..] > However, if I add a SAN to the request: > [..] > the resulting request has the

Multi-valued RDN in Subject Alternative Name extension

I can successfully add a multi-value RDN to the Subject of a certificate request using the + format in the config file: distinguished_name = req_dn [ req_dn ] O=Acme CN=Bloggs +C=GB However, if I add a SAN to the request: subjectAltName = @alt_names [ alt_names

Re: Certificate subject match validation

r connection > */ > > followed by (per connection): > > SSL_set1_host(ssl, "www.example.org"); > SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_WILDCARDS > | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT); > > which also insists on a DNS subject altname (the preferred way

Re: Certificate subject match validation

t once */ SSL_set_verify(ssl, SSL_VERIFY_PEER, NULL); /* Per connection */ followed by (per connection): SSL_set1_host(ssl, "www.example.org"); SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_WILDCARDS | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT); which

Re: Certificate subject match validation

> I am writing a SSL/TLS client (using Boost.Beast but underlying it's using > OpenSSL) and although I have set on the SSL context the 'verify_peer' flag, > there is no verification to prove the server presents an X509 which > contains in the Subject Alternative Names the hostname of

Re: Certificate subject match validation

509 which > contains in the Subject Alternative Names the hostname of that server. > > As this is probably the dumbest type of attack someone could do (using a > valid certificate with another domain name), I am thinking I'm doing > something wrong. But from the documentation, I saw

Certificate subject match validation

I am writing a SSL/TLS client (using Boost.Beast but underlying it's using OpenSSL) and although I have set on the SSL context the 'verify_peer' flag, there is no verification to prove the server presents an X509 which contains in the Subject Alternative Names the hostname of that server

[no subject]

[no subject]

[no subject]

[no subject]

[no subject]

Hi, After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with SCTP as transport. OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h. We have our own custom SCTP implementation (also implements custom BIO METHODS, do not use the default methods), so we need to remove the

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

On 29/08/2019 17:05, Hubert Kario wrote: On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote: ... that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA instead of trying to make 1024 bit

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

* I've another question, based on your suggestion Salz Rich, this config @SECLEVEL can be set per host/domain, or is it impossible? It totally depends on which webserver you are running and what it’s configuration allows. I’m not able to answer webserver config questions BTW.

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

Thank you guys for the answers! I've another question, based on your suggestion Salz Rich, this config @SECLEVEL can be set per host/domain, or is it impossible? On Thu, Aug 29, 2019 at 12:38 PM Salz, Rich wrote: > >- We haven't control of the server who are using DH key size of 1048 >

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote: > Our server runs with DH key size of 2048 bits and we are trying to make > requests with httparty(https://github.com/jnunemaker/httparty) to a server > that uses DH key size of 1024 bits, i want to now for what reason we are >

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

* We haven't control of the server who are using DH key size of 1048 bits. In order to work with this kind of server (terribly poor security characteristics), you need to add “@SECLEVEL=0” to your OpenSSL configuration.

Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

Our server runs with DH key size of 2048 bits and we are trying to make requests with httparty(https://github.com/jnunemaker/httparty) to a server that uses DH key size of 1024 bits, i want to now for what reason we are getting this error SSL_connect returned=1 errno=0 state=error: dh key too

CRL issuer does not match CA subject

that subject line is /Subject: C = us, ST = ca, O = test, CN = intermediate CA/ I then create the CRL using: /openssl ca -config $INTRMDT_CONF //-gencrl -out $INTRMDT_CRL/ When I dump the CRL, though, the issuer is /Issuer: /C=us/ST=ca/O=test/CN=intermediate ca/ When I put my certificate through https

Re: [openssl-users] Subject CN and SANs

> On Dec 24, 2018, at 5:51 PM, Kyle Hamilton wrote: > If a certificate identifies an Issuer, then the certificate cannot contain an > empty sequence of RDNs in the Subject and still be conformant to PKIX. Yes, CA certificates need to have a non-empty subject name if they're t

Re: [openssl-users] Subject CN and SANs

In order for an Issuer to exist in PKIX, it must be the Subject of another Certificate (or of a trust anchor). If a certificate identifies an Issuer, then the certificate cannot contain an empty sequence of RDNs in the Subject and still be conformant to PKIX. This is because the Subject

Re: [openssl-users] Subject CN and SANs

I’m not sure, heh. ;-) -F > On Dec 24, 2018, at 3:17 AM, Walter H. wrote: > > and which CA does this as the forum guidelines say? > >> On 23.12.2018 22:50, Felipe Gasper wrote: >> Actually, per the latest CA/Browser forum guidelines, subject.CN is not only >> optional but “discouraged”. >>

Re: [openssl-users] Subject CN and SANs

A bit off-topic but is it also a good idea to follow these guidelines in non-browser use cases, for example for a client certificate which is used to autenticate on a TLS connection which will be used for another protocol such as MQTT? In this case the SubjectCN looks like a "natural" place to put

Re: [openssl-users] Subject CN and SANs

and which CA does this as the forum guidelines say? On 23.12.2018 22:50, Felipe Gasper wrote: Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”. -FG smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list

Re: [openssl-users] Subject CN and SANs

> On Dec 23, 2018, at 6:01 PM, Kyle Hamilton wrote: > > You're right, I typoed. SubjectDN is non-optional. But it can, as > you mentioned, be an empty sequence. > > But for PKIX purposes, it can't be empty if it's an Issuer (because > IssuerDN can't be empty in the certificates that it

Re: [openssl-users] Subject CN and SANs

You're right, I typoed. SubjectDN is non-optional. But it can, as you mentioned, be an empty sequence. But for PKIX purposes, it can't be empty if it's an Issuer (because IssuerDN can't be empty in the certificates that it issues). -Kyle H On Sun, Dec 23, 2018 at 3:35 PM Viktor Dukhovni

Re: [openssl-users] Subject CN and SANs

Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”. -FG > On Dec 23, 2018, at 4:29 PM, Kyle Hamilton wrote: > > SubjectCN is an operational requirement of X.509, I believe. It's not > optional in the data structure, at any rate. > > -Kyle

Re: [openssl-users] Subject CN and SANs

> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton wrote: > > SubjectCN is an operational requirement of X.509, I believe. You're confusing the DN and the CN. > It's not optional in the data structure, at any rate. The subjectDN is not optional, but it can be empty sequence, and is empty for

Re: [openssl-users] Subject CN and SANs

SubjectCN is an operational requirement of X.509, I believe. It's not optional in the data structure, at any rate. -Kyle H On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson wrote: > > > Salz, Rich via openssl-users wrote: > > Putting the DNS name in the CN part of the subjectDN has been

Re: [openssl-users] Subject CN and SANs

2:bb:2b:cb:dd Signature Algorithm: sha256WithRSAEncryption Issuer: Validity Not Before: Dec 23 18:56:08 2018 GMT Not After : Jan 22 18:56:08 2019 GMT Subject: X509v3 extensions: X509v3 Subject Alternat

Re: [openssl-users] Subject CN and SANs

Salz, Rich via openssl-users wrote: > Putting the DNS name in the CN part of the subjectDN has been > deprecated for a very long time (more than 10 years), although it > is still supported by many existing browsers. New certificates > should only use the subjectAltName extension.

Re: [openssl-users] Subject CN and SANs

I guess its a matter of which Linux you use, CentOS 7 doesn't give this warning; CentOS 6 warns about this; a Debian (don't really know which release) uname -a Linux a2f78 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux does warn ... Walter On 23.12.2018 13:21, Felipe

Re: [openssl-users] Subject CN and SANs

Wow that’s pretty bad .. is that the current version of httpd?? That’d be worth a big report if so, IMO, though I’d imagine it’s an issue they’re aware of. -FG > On Dec 23, 2018, at 6:53 AM, Walter H. wrote: > > > I tried the following > > the certificate had a CN oftest.example.com

Re: [openssl-users] Subject CN and SANs

I tried the following the certificate had a CN oftest.example.com and in subjectAltNames dNS were test.example.com and test.example.net when the Apache ServerName is test.example.net I get this warning [Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN)

Re: [openssl-users] Subject CN and SANs

Does Apache only examine CN=, or does it also check subjectAltNames dNS entries? -Kyle H On Sun, Dec 23, 2018 at 3:25 AM Walter H. wrote: > > On 23.12.2018 03:47, Salz, Rich via openssl-users wrote: > > > >. New certificates should only use the subjectAltName extension. > > > >> Are

Re: [openssl-users] Subject CN and SANs

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote: > >. New certificates should only use the subjectAltName extension. Are any CAs actually doing that? I thought they all still included subject.CN. Yes, I think commercial CA's still do it. But that doesn't make my statement

Re: [openssl-users] Subject CN and SANs

> >. New certificates should only use the subjectAltName extension. >Are any CAs actually doing that? I thought they all still included > subject.CN. Yes, I think commercial CA's still do it. But that doesn't make my statement wrong :) -- openssl-users mailing list To

Re: [openssl-users] Subject CN and SANs

> On Dec 22, 2018, at 9:12 PM, Salz, Rich via openssl-users > wrote: > > Putting the DNS name in the CN part of the subjectDN has been deprecated for > a very long time (more than 10 years), although it is still supported by many > existing browsers. New certificates should only use the

Re: [openssl-users] Subject CN and SANs

Putting the DNS name in the CN part of the subjectDN has been deprecated for a very long time (more than 10 years), although it is still supported by many existing browsers. New certificates should only use the subjectAltName extension. -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] Subject CN and SANs

It shouldn’t matter. Technically subject.CN is deprecated anyway, but all the CAs still create it. -FG > On Dec 22, 2018, at 4:29 PM, Walter H. wrote: > > Hello, > > I found several different certificates on the net > > some are like this: > > CN=example.com > SANs areDNS:example.com,

[openssl-users] Subject CN and SANs

Hello, I found several different certificates on the net some are like this: CN=example.com SANs areDNS:example.com, DNS:www.example.com and some are like this: CN=www.example.com SANs areDNS:example.com, DNS:www.example.com does this matter or is one them the preferred one?

Re: [openssl-users] [openssl]: Subject alternative names not recognized when signing certificates

> On Sep 22, 2018, at 8:28 AM, Carsten wrote: > > I can sign certificate requests successfully, BUT > if the request contains SAN attributs (subjectalternatenames) they are > ignored -not visible in the signed certificate. > > I found many exambles how to create a SAN-Certificate using

[openssl-users] [openssl]: Subject alternative names not recognized when signing certificates

Hi list, this is about setting up a certificate authority to sign incoming (forgeign) certificate requests. I have installed /var/caintermed # openssl version -a OpenSSL 1.1.2-dev xx XXX built on: Fri Sep 21 10:19:51 2018 UTC platform: linux-armv4

[openssl-users] (no subject)

Get Outlook for Android -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

e: Tue, 31 Jul 2018 06:48:59 -0700 (MST) Subject: Looking for exact openssl commands to do the following from command line ? import java.security.KeyFactory; import java.security.Signature; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class SHA256RSA { public s

[openssl-users] (no subject)

-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

Gesendet von Mail für Windows 10 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

Gesendet von Mail für Windows 10 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

Gesendet von Mail für Windows 10 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

import rlcompleter import readline readline.parse_and_bind("tab: complete") -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

Gesendet von Mail für Windows 10 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] x509: recent change in Subject and Issuer printing?

Matt > > $ /usr/local/opt/openssl/bin/openssl version > OpenSSL 1.0.2n  7 Dec 2017 > > $ /usr/local/opt/openssl/bin/openssl x509 -in thawte.pem -noout -text | > grep -E 'Issuer:|Subject:' >     Issuer: C=US, O=thawte, Inc., OU=Certification Services > Division, OU=(c)

[openssl-users] x509: recent change in Subject and Issuer printing?

| grep -E 'Issuer:|Subject:' Issuer: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Subject: C=US, O=Thawte, Inc., CN=Thawte SSL CA $ openssl version OpenSSL 1.1.0f 25 May 2017 $ openssl x509

Re: [openssl-users] openssl.cnf asking Subject Alternative Names certificates.

Hi, On 13 October 2017 at 12:03, lists <li...@rustichelli.net> wrote: > On 10/10/2017 05:40 PM, Jorge Novo wrote: > > As most of us know, the Google Chrome Navigator ask about Subject > Alternative Name instead the Common Name. > > I want to distribute a little *openss

Re: [openssl-users] openssl.cnf asking Subject Alternative Names certificates.

On 10/10/2017 05:40 PM, Jorge Novo wrote: Hi everyone,   As most of us know, the Google Chrome Navigator ask about Subject Alternative Name instead the Common Name. I want to distribute a little /openssl.cnf/ file for creation the CSR files with my specific values and establish the Subject

[openssl-users] openssl.cnf asking Subject Alternative Names certificates.

Hi everyone, As most of us know, the Google Chrome Navigator ask about Subject Alternative Name instead the Common Name. I want to distribute a little *openssl.cnf* file for creation the CSR files with my specific values and establish the Subject Alternative Name = Common Name. I want yo ask

[openssl-users] Creating requests and certificates with Subject Alternative Names

I'm creating X509 certificate requests and certificates in code, trying to add X509v3 Subject Alternative Name, with 1.1.0f. But if I add a list of four domains, ie: www1.mydomain www2.mydomain www3.mydomain www4.mydomain The certificate seems to ignore some and repeat others: X509v3

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

On Wed, Sep 20, 2017 at 5:48 PM, Jordan Brown <open...@jordan.maileater.net> wrote: > ... > The above also works with "authorityCertSerialNumber", see > >https://tools.ietf.org/html/rfc5280#section-4.2.1.1 > > If, however, the newer certificate has a differ

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

On 9/20/2017 2:25 PM, Viktor Dukhovni wrote: >> On Sep 20, 2017, at 12:33 PM, Jordan Brown <open...@jordan.maileater.net> >> wrote: >> >> Q: Does OpenSSL's trust-list verification support trusting multiple >> certificates with the same subject n

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

> On Sep 20, 2017, at 12:33 PM, Jordan Brown <open...@jordan.maileater.net> > wrote: > > Q: Does OpenSSL's trust-list verification support trusting multiple > certificates with the same subject name and overlapping validity periods? > > In more detail: >

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

On 9/20/2017 10:28 AM, Walter H. via openssl-users wrote: > On 20.09.2017 18:33, Jordan Brown wrote: >> >> Q:  Does OpenSSL's trust-list verification support trusting multiple >> certificates with the same subject name and overlapping validity periods? >> > do these

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

On 20.09.2017 18:33, Jordan Brown wrote: Q: Does OpenSSL's trust-list verification support trusting multiple certificates with the same subject name and overlapping validity periods? do these replacement certificates have the same serial number and the same private key? smime.p7s

[openssl-users] Trusting certificates with the same subject name and overlapping validity periods

Q:  Does OpenSSL's trust-list verification support trusting multiple certificates with the same subject name and overlapping validity periods? In more detail: We have customers who issue replacement certificates with the same subject name and different validity periods.  We'd like to be able

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

> Does your response mean, that RSA-PSS meanhile _is_ fully supported in 1.1.0? I hesitate to say fully, because there are no doubt parts that don't work. But RSAPSS signatures are supported. But more importantly, 1.1.1 not 1.1.0 > Any estimations about how much work has to be done for

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

Am 27.06.2017 um 14:18 schrieb Salz, Rich via openssl-users: 1.0.2 does not have full RSA-PSS support; you can’t use it. Thanks Rich, in my case it works, because we partially do the verification (and algo selection) work externally. We just need to access the public key which is rsa in

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

1.0.2 does not have full RSA-PSS support; you can’t use it. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

rsaEncryption or id-RSASSA-PSS as OID for the subject public key. But when listing the certs's contents or during verification, openssl v1.0.2h bails out: 12392:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231: 12392:error:0B07706F:x509

Re: [openssl-users] (no subject)

On 27/06/17 01:05, Neetish Pathak wrote: > Hi , > > 1) I am working with a client and server program and want to use > ECDHE-ECDSA type ciphers. > I see that default Elliptic curve group supported is X25519. (when I > check client and server logs on wireshark) > I wish to generate a

[openssl-users] (no subject)

Hi , 1) I am working with a client and server program and want to use ECDHE-ECDSA type ciphers. I see that default Elliptic curve group supported is X25519. (when I check client and server logs on wireshark) I wish to generate a self-signed certificate for X25519 curve. But I am unable to do

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

id-RSASSA-PSS as OID for the subject public key. > > But when listing the certs's contents or during verification, openssl > v1.0.2h bails out: >> 12392:error:0609E09C:digital envelope >> routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231

[openssl-users] X509 subject public key id-RSASSA-PSS

Dear OpenSSSL users, we recently came across a certificate with OID: id-RSASSA-PSS aka rsassaPss in x509 subjects public key AlgorithmIdentifier. According to rfc4056 it is legitimate to use rsaEncryption or id-RSASSA-PSS as OID for the subject public key. But when listing the certs's

Re: [openssl-users] CSR with multiple subject names?

On 01/06/2017 16:26, l vic wrote: I am working with service with TLS authn that uses subject name to authenticate client. Is it possible to use list of subject names in client certificate so that service could authenticate several clients with the same key/certificate? If not, would

Re: [openssl-users] CSR with multiple subject names?

By default, TLS only does server-side verification. If you are using client certificates, you will have to write some code for your application. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz -- openssl-users mailing list To

[openssl-users] CSR with multiple subject names?

I am working with service with TLS authn that uses subject name to authenticate client. Is it possible to use list of subject names in client certificate so that service could authenticate several clients with the same key/certificate? If not, would it be possible to use alternative subject names

[openssl-users] (no subject)

Nguyễn Văn Công.pdf -- Nguyễn Văn Công -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

Betreff: Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension? That attribute is not currently supported. Someone would have to write ASN1 parsing code. There are examples all over the place within OpenSSL; see the various d2i_XXX and i2d_XXX functions. There are macro

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

sl.org] Im Auftrag von Dr. Stephen Henson Gesendet: Dienstag, 9. Mai 2017 18:06 An: openssl-users@openssl.org Betreff: Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension? On Tue, May 09, 2017, Matthias Ballreich wrote: > Here are nor some more details, which may help

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

On Tue, May 09, 2017, Matthias Ballreich wrote: > Here are nor some more details, which may help you to better understand. > > > My Certificate contains the SubjectDirectoryAttributes-Extension with the > following Attributes: > > OID : Value >

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

That attribute is not currently supported. Someone would have to write ASN1 parsing code. There are examples all over the place within OpenSSL; see the various d2i_XXX and i2d_XXX functions. There are macro/define’s available to make the job easier. But, it is not really documented. Maybe

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

:44:48 An: openssl-users@openssl.org Betreff: C++ How to parse Subject Directory Attributes Extension? Hi there, can anyone tell me how to parse a the Subject Directory Attribute Extension of a X509-Certificate in C++ with OpenSSL? I don't found any documentation or piece of code in the Githu

[openssl-users] C++ How to parse Subject Directory Attributes Extension?

Hi there, can anyone tell me how to parse a the Subject Directory Attribute Extension of a X509-Certificate in C++ with OpenSSL? I don't found any documentation or piece of code in the Github Repo of OpenSSL. I read the Extension this way: int loc = X509_get_ext_by_NID(cert

Re: [openssl-users] Escaped Issuer/Subject

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of c.hol...@ades.at > Sent: Wednesday, April 12, 2017 00:47 > > I thought about escaping regarding DN itself (LDAP DN). It's an X.400 DN. LDAP is a protocol and an API; there's no necessary relationship between X.509

Re: [openssl-users] Escaped Issuer/Subject

> I thought about escaping regarding DN itself (LDAP DN). Look up the -nameopt flag in, say, x509.pod Then if you need C code, trace through what apps/x509.c does. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Escaped Issuer/Subject

I thought about escaping regarding DN itself (LDAP DN). https://www.ietf.org/rfc/rfc4514.txt https://www.ibm.com/support/knowledgecenter/en/ssw_i5_54/rzahy/rzahyunderdn.htm https://msdn.microsoft.com/en-us/library/aa366101%28v=vs.85%29.aspx Best regards -- openssl-users mailing list To

  1   2   3   4   5   6   >