Hmm. thought so that it is quite hard to derive the correct p_https_host dynamically if it is actually different from the p_url .
I have understood that apache reverse proxying is ultimate solution to this challenge, but I still would like to understand and have a proper fix.
Is it time to turn to MOS and if so, are there patches which brings ease?
After googling furiously I found this: https://security.stackexchange.com/questions/113267/can-i-read-the-domain-name-from-https-before-ssl-handshake
Without SNI, the domain first appears in cleartext in the Server Hello of the TLS handshake (In the rdnSequence of the Certificate field).
and it raises the question is it possible to get the domain name from in the rdnSequence of the Certificate field in the 'Server Hello of the TLS handshake' ?
1 person found this helpful
please, read also this Re: utl_http.request on ssl site fails with ORA-29024. I'm not sure if by "programmatically" you meant also invoking the openssl command, but it should not be a big deal to process its output.
Yes indeed this aint easy.
To be frank I assume that some of errors I have been able to generate while iterating the p_https_host are due 'snakeoil self-signed certs' somewhere deep where I can't see from the plsql.
Only indication about it is that the error remains the same ORA-29024 in our pretty patched 12.2.x for them regardless about the p_https_host.
The valid certificate at the ws server end gives more reasonable errors like: ORA-28788, ORA-24263 or just works when p_https_host appears to be correct.
For 12.1.x there is no need to define p_https_host.
For the programmatic fetch I dreamed about the MLE python script something like ssl-check.py or so, but it seems that its still in vbox pampering phase its not said that we are allowed to wireshark db.