Archived
This forum has been archived. Please start a new discussion on GitHub.
IceSSL encoding
in Bug Reports
First of all,
Happy New Year and the best wishes to the ZeroC team and their excellent product !
The Ice Manual states that the default value for the 'encoding' attribute of both 'public' and 'private' elements is PEM. This is not true. The default value is 0.
The problem is in:
IceSSL::CertificateFile::CertificateFile( ... )
: _filename(""),
_encoding(0) // <-- problem here
It should be:
IceSSL::CertificateFile:CertificateFile( ... )
: _filename(""),
_encoding(SSL_FILETYPE_PEM)
I would propose also to extend the error messages adding also the encoding type:
PEM, DER(ASN1), or unknown.
I have also a different philosophical question: Ice has the good mechanism for configuration, why did you decide to use for the IceSSL plugin an absolutely different format -- XML.
Cheers, Nikolai
Happy New Year and the best wishes to the ZeroC team and their excellent product !
The Ice Manual states that the default value for the 'encoding' attribute of both 'public' and 'private' elements is PEM. This is not true. The default value is 0.
The problem is in:
IceSSL::CertificateFile::CertificateFile( ... )
: _filename(""),
_encoding(0) // <-- problem here
It should be:
IceSSL::CertificateFile:CertificateFile( ... )
: _filename(""),
_encoding(SSL_FILETYPE_PEM)
I would propose also to extend the error messages adding also the encoding type:
PEM, DER(ASN1), or unknown.
I have also a different philosophical question: Ice has the good mechanism for configuration, why did you decide to use for the IceSSL plugin an absolutely different format -- XML.
Cheers, Nikolai
0
Comments
-
Re: IceSSL encodingOriginally posted by nsns
Happy New Year and the best wishes to the ZeroC team and their excellent product !The Ice Manual states that the default value for the 'encoding' attribute of both 'public' and 'private' elements is PEM. This is not true. The default value is 0.
The problem is in:
IceSSL::CertificateFile::CertificateFile( ... )
: _filename(""),
_encoding(0) // <-- problem hereI have also a different philosophical question: Ice has the good mechanism for configuration, why did you decide to use for the IceSSL plugin an absolutely different format -- XML.
For example, it is very straightforward in XML to accept one or more occurrences of a value, such as a certificate. The semantics of properties, however, require each property name to be unique, in which case specifying multiple values requires either artificially unique property names, or overly complex property values.
I've recently had an opportunity to review the SSL configuration mechanism because I'm implementing an SSL plug-in for the Java mapping. Although the Java version will not use an XML configuration file, I still feel it is appropriate in C++ given the variety of configuration options provided by OpenSSL. The SSL capabilities in Java offer much fewer options, therefore properties will be used to configure the Java plug-in.
Take care,
- Mark0 -
I see your point. But consider also an Ice-based application point of view. I like to have a possibility for the flexible configuration but also I know that in the most cases my application will need only three parameters: capath, certificate, and private key. And for a sake of these three properties I need to provide a 14-line XML-file plus dtd.
The possible workaround is to generate the XML-files on the fly but this will complicate my programs and will require the write access to the underlying filesystem.
The other solution could be to set the SSL properties programatically but it is not clear how can I do it.
The different question: how can I set up my own certificate verification procedure ?
For example, if my certificates contain an application specific extension I'd like to check it.
Cheers, Nikolai0 -
Originally posted by nsns
I see your point. But consider also an Ice-based application point of view. I like to have a possibility for the flexible configuration but also I know that in the most cases my application will need only three parameters: capath, certificate, and private key. And for a sake of these three properties I need to provide a 14-line XML-file plus dtd.The possible workaround is to generate the XML-files on the fly but this will complicate my programs and will require the write access to the underlying filesystem.
The other solution could be to set the SSL properties programatically but it is not clear how can I do it.The different question: how can I set up my own certificate verification procedure ?
For example, if my certificates contain an application specific extension I'd like to check it.
Take care,
- Mark0 -
I've recently had an opportunity to review the SSL configuration mechanism because I'm implementing an SSL plug-in for ...Yes, I agree that the XML configuration is overkill for simple cases.
The attached tarball contains my workaround. I use IceSSL but without XML configuration.
Of course, this is dirty and non-portable trick but maybe the code will be interesting to you
in sight of the future modifications.
Yet another comment on the IceSSL documentation. The default value for the certificate verification depth is -1 (probably, means infinite) but in the doc it is 10. It is not clear why the RSA key size is the mandatory argument. This value is a property of key/cert and can be extracted from there.
--
Cheers, Nikolai0