We're currently experiencing an issue with an Azure AD based Open ID Connect Provider and it's integration with AWS Cognito Identity Pools.
At a basic level our authentication flow is:
User goes to our application
User is redirected to Office 365(Azure AD) to authenticate
User is sent back to our application and we forward the OIDC details obtained from the Auth step to obtain the Identity details from the Cognito Identity Pool
That third step is failing intermittantly with Cognito responding with the following error "OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint"
It's important to note we are repeating the third step numerous times without changing what we are sending to Cognito and sometimes it works and sometimes it doesn't.
We have followed the steps outlined on this page below to obtain the Thumprint
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
Which ultimately results in us using openssl with this command to obtain a single thumbprint.
.\openssl s_client -servername login.microsoftonline.com -showcerts -connect login.microsoftonline.com:443
When using OIDC with Azure AD is it possible that there is more than one valid thumprint that we need to configure? Given the SSL Certificates rotate frequently I'm assuming the answer to this is yes but am unclear around how we obtain all the required thumprints.
Yes, there are multiple thumbprints for Azure. See https://www.microsoft.com/pki/mscorp/cps/default.htm
Microsoft IT TLS CA 1
CA Certificate: Microsoft IT TLS CA 1.crt
Thumbprint: 41 7e 22 50 37 fb fa a4 f9 57 61 d5 ae 72 9e 1a ea 7e 3a 42
CRL: http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft IT TLS CA 1.crl
Authority Key Identifier: e5 9d 59 30 82 47 58 cc ac fa 08 54 36 86 7b 3a b5 04 4d f0
Microsoft IT TLS CA 2
CA Certificate: Microsoft IT TLS CA 2.crt
Thumbprint: 54 d9 d2 02 39 08 0c 32 31 6e d9 ff 98 0a 48 98 8f 4a df 2d
CRL: http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft IT TLS CA 2.crl
Authority Key Identifier: e5 9d 59 30 82 47 58 cc ac fa 08 54 36 86 7b 3a b5 04 4d f0
Microsoft IT TLS CA 4
CA Certificate: Microsoft IT TLS CA 4.crt
Thumbprint: 8a 38 75 5d 09 96 82 3f e8 fa 31 16 a2 77 ce 44 6e ac 4e 99
CRL: http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft IT TLS CA 4.crl
Authority Key Identifier: e5 9d 59 30 82 47 58 cc ac fa 08 54 36 86 7b 3a b5 04 4d f0
Microsoft IT TLS CA 5
CA Certificate: Microsoft IT TLS CA 5.crt
Thumbprint: ad 89 8a c7 3d f3 33 eb 60 ac 1f 5f c6 c4 b2 21 9d db 79 b7
CRL: http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft IT TLS CA 5.crl
Authority Key Identifier: e5 9d 59 30 82 47 58 cc ac fa 08 54 36 86 7b 3a b5 04 4d f0
Related
I have a clean Kona112 Javacard and I'm going to a put a Receipt key into it and then I want to delete it from the card or replace its value.
Step 1: I tried to create a new key on the card with Key Version == 0x71 (Quoted from GP UICC Configuration v1.0.1: "Key Version number '71' with Key Identifier '01' is reserved for the Receipt Key, which is a DES key"):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 B5 75 C3 8D 89 DC F9 B1 74 CC 1E 93 C4 45 C8 2C 03 CD 80 0F EC EA 8D 6F 8F BF 7D D0 // PUT KEY
<-- 6A 80
==> Quoted from GP UICC Configuration v1.0.1: "6A80 = ISO compliant standard status word for Algorithm not supported"
Step 2: As I received "Algorithm not supported" error, I enabled Delegated Management on my card and retried step #1:
[Select ISD]
[Successful Mutual Authentication]
[Proprietary APDU command to enable Delegated Management]
--> 84 D8 00 01 1F 71 80 10 1A F6 96 45 2A ED 66 86 75 DF FC 8B 59 55 6D 0B 03 CD 80 0F 87 03 E4 1A 8D AB 90 EC
<-- 71 CD 80 0F 90 00
Good! I successfully put the Receipt key in the card.
Step 3: Now, I want to delete it:
[Select ISD]
[Successful Mutual Authentication]
--> 80 E4 00 00 06 D0 01 01 D2 01 71 // Delete APDU Command to delete a key with Key ID = 01 and Key Version = 71
<-- 6A 80
As you see above, I received 6A 80 error status words. It is mentioned in the answer of my other question (and also in GP UICC Configuration v1.0.1) that the Key Deletion feature is optional.
So in step #4 I tried to replace the key with another value.
Step 4: I changed P1 in PUT Key APDU command from 0x00 (create key) to 0x71 (overwrite):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 71 01 1F 71 80 10 E9 06 6B 8E D8 05 50 34 D5 A7 71 3B 81 CB BE 7A 03 CD 80 0F 91 0D BC E9 96 25 7E 89
<-- 6A 88
==> Quoted from GP UICC Configuration v1.0.1: "6A88 = Referenced data not found"
Well, that's weird, I received "Referenced data not found". So I tried the PUT Key command with P1 = 0X00 (Create Key) again:
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 31 35 5C 0C E3 27 FD D5 8B 6B AE 37 56 CA 0D F2 03 CD 80 0F 0B EB 16 CF FF CE 4C 09
<-- 69 85 // Conditions of used not satisfied.
Well, I tried both cases of step #3 (P1 = 0x00 and P1 = 0x71) with disabled Delegated Management too, but nothing changed and I respectively received 0x6A80 and 0x6A88.
What's wrong? How can I fix the delete or modify this key?
Note that I tried all the steps in secure channel with SecurityLevel = 0x03 too. Nothing changed.
Update:
I tried to list the available keys in the card using GET DATA APDU command with Key Info Template tag, but I only can see ISD ENC, MAC and KEK keys in the APDU Response (For both DM enabled and DM Disabled.
--> 80 CA 00 E0 00
<-- E0 12 C0 04 01 01 80 10 C0 04 02 01 80 10 C0 04 03 01 80 10 90 00
One idea: The receipt key (and you also have to store a token key) might be linked to a application security domain. Select the Security Domain with Token Verification privilege and the Security Domain with Receipt Generation
privilege, maybe they are different from the ISD. I assume also that during [Proprietary APDU command to enable Delegated Management] a new application security domain (ASP) was created. Try the select these new security domains and list there all the keys using the key template flag and execute then your PUT KEY operations against one of these security domains. GET STATUSis the command to be used for listing the SDs. All the existing OS tools like GPShell and GlobalPlatformPro can do this.
A project I work on uses the crypto module publicEncrypt function to encrypt some 32 bytes long session keys.
Due to a compatibility issue with the node-forge library we realized that, about once in a hundered iterations, the output of the publicEncrypt is 255 bytes long instead of 256.
We verified this behavior in Chrome, Firefox, and Opera, however we could not replicate the issue in a unit test (using Jest), because in this setting the output of publicEncrypt is consistently 256 bytes long.
Is this an expected behavior of the crypto module? By checking the RFC https://www.rfc-editor.org/rfc/rfc8017#page-28 this seems to be a bug to me.
Below the public key used in our tests and the unit test to illustrate the issue. To clarify, the unit test succeeeds in Jest, but calls to function publicCipher done within a browser sometimes create a 255 bytes long encrypted output.
Key Algorithm: RSA
Key Parameters: 05 00
Key Size: 2048
Key SHA1 Fingerprint: 89 BD 3D 96 DA 7E 65 60 DE B5 C2 33 5D 22 89 95 F0 44 90 EB
Public Key: 30 82 01 0A 02 82 01 01 00 AA 20 54 0F A4 1C 2A B3 BA FA C2 FB B3 C3 17 53 A0 3F C8 AB 7F 22 E0 60 E6 0A AD 80 0D EC 07 C7 FD E3 4A CD 5C 77 BC 0E FE 63 9F 6D 40 6B 21 84 20 2E F9 C4 6D 93 01 E4 CB EB D0 A5 C2 F5 F5 4F C4 F2 9E D8 C7 F5 2A C4 F2 D8 2D 87 A9 18 2B 6D B3 E2 04 EA 7B A6 5D 4A 55 1A 6D C9 1A E1 AF 4B 0C E1 FD 43 74 37 5B 1A 70 11 86 E7 E4 40 DD 6B 27 7C 72 C5 D0 15 79 B0 6D BC 07 F1 43 C7 BF D3 13 EC 94 83 D3 77 44 7B 58 2E 37 82 22 AC 07 7E 61 5F 7D A7 57 09 6C DB 24 24 5D 10 ED 83 DC AE 35 CE 6C 1E AB C2 9E 3A 1D 99 01 F9 0E 2C 6B A4 74 E0 87 1E 86 04 BC 72 A3 3E CF 46 76 57 AC 78 EC 41 AD 2D 82 E5 F5 A8 76 9D 25 0A 87 D8 D4 74 FA 64 9D 14 BF F4 17 B5 CF 2E D7 FF 71 41 94 5D 30 56 F0 17 9C ED 2F CB 66 D3 E5 7F 99 F9 31 42 EE DE 16 AE ED 38 BD E6 9A DD A6 50 75 30 5B D5 02 03 01 00 01
import { publicEncrypt, randomBytes } from 'crypto'
import constants from 'constants'
describe('Encryption output size test.', () => {
const publicKeyPem = `-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqiBUD6QcKrO6+sL7s8MX
U6A/yKt/IuBg5gqtgA3sB8f940rNXHe8Dv5jn21AayGEIC75xG2TAeTL69ClwvX1
T8TyntjH9SrE8tgth6kYK22z4gTqe6ZdSlUabcka4a9LDOH9Q3Q3WxpwEYbn5EDd
ayd8csXQFXmwbbwH8UPHv9MT7JSD03dEe1guN4IirAd+YV99p1cJbNskJF0Q7YPc
rjXObB6rwp46HZkB+Q4sa6R04IcehgS8cqM+z0Z2V6x47EGtLYLl9ah2nSUKh9jU
dPpknRS/9Be1zy7X/3FBlF0wVvAXnO0vy2bT5X+Z+TFC7t4Wru04veaa3aZQdTBb
1QIDAQAB
-----END PUBLIC KEY-----
`
it('Should create encrypted keys of 256 bytes.', (done) => {
for (let i = 0; i < 1000; i++) {
expect(publicCipher(publicKeyPem, randomBytes(32)).length).toEqual(256)
}
done()
})
})
function publicCipher(publicKeyPem: string, clearText: Buffer): Buffer {
return publicEncrypt({ key: publicKeyPem, padding: constants.RSA_PKCS1_PADDING }, clearText)
}
Update: the issue is due to the removal of leftmost 0 bytes.
I will try find a way to make this issue reproducible, meanwhile I think the following unit test should clarify what is happening (the key pair is self signed and used for testing purposes only, so I have no problem publishing the private key):
import forge from 'node-forge'
import { privateDecrypt } from 'crypto'
import * as constants from 'constants'
it('buggy encrypted random bits from crypto', (done) => {
const encryptedRandomBits = 'inYgmlfL4y0ab5tplmDKCeP0p7q2lcnMqUDjfQpUjqFJkiqoVXQ9A8pA8hyWBf2onea/+iVMtU/Xj9IyLvPQiLkUE9OWptzmwTqnXzzG3ulXUIjud+rpvJdENSJzsX7IwiNaAPWo3EmM57B/fdXaPPGZME203SDPRVWst2XZw7zBfeM2XmS4nSMvs7NM7rGR/Ti3Hb+p7D+PJZUm7oi3npFZHSS1C/SsAXUaAja3HPaXuve+VZfclqrSbQ2P+45cRyQpvcf+ueXqdk/Yqg/sOuufR8eFDyDgRudzMOzLuH6rzrNKYtMXpD9ueFWFRh0G2wOlXNc/acbv0nSN5Dvu'
const publicKeyPem = `-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqiBUD6QcKrO6+sL7s8MX
U6A/yKt/IuBg5gqtgA3sB8f940rNXHe8Dv5jn21AayGEIC75xG2TAeTL69ClwvX1
T8TyntjH9SrE8tgth6kYK22z4gTqe6ZdSlUabcka4a9LDOH9Q3Q3WxpwEYbn5EDd
ayd8csXQFXmwbbwH8UPHv9MT7JSD03dEe1guN4IirAd+YV99p1cJbNskJF0Q7YPc
rjXObB6rwp46HZkB+Q4sa6R04IcehgS8cqM+z0Z2V6x47EGtLYLl9ah2nSUKh9jU
dPpknRS/9Be1zy7X/3FBlF0wVvAXnO0vy2bT5X+Z+TFC7t4Wru04veaa3aZQdTBb
1QIDAQAB
-----END PUBLIC KEY-----
`
const privateKeyPem = `-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAqiBUD6QcKrO6+sL7s8MXU6A/yKt/IuBg5gqtgA3sB8f940rN
XHe8Dv5jn21AayGEIC75xG2TAeTL69ClwvX1T8TyntjH9SrE8tgth6kYK22z4gTq
e6ZdSlUabcka4a9LDOH9Q3Q3WxpwEYbn5EDdayd8csXQFXmwbbwH8UPHv9MT7JSD
03dEe1guN4IirAd+YV99p1cJbNskJF0Q7YPcrjXObB6rwp46HZkB+Q4sa6R04Ice
hgS8cqM+z0Z2V6x47EGtLYLl9ah2nSUKh9jUdPpknRS/9Be1zy7X/3FBlF0wVvAX
nO0vy2bT5X+Z+TFC7t4Wru04veaa3aZQdTBb1QIDAQABAoIBAAEK0KkF3txOHJOj
tSoNRGvRPALNNiqvCDjwkM6Lh0om6gHF+Asceqz21wJnh3EAlBAkaYhQCYoF7k/k
B9fxbM7PzJK3jkYMvIcmVuURXqIJeoQkdpFKXCDz84T/qef/DG0oR0ZuBFbNCym4
U1xdH14kMEl9t8Ah7jhF4iCSwzsEG/YUU2czCkHwnFaALsnTk6sXhcUvy8BFelIP
TU3QWxMIv2hmEJcn8GXXtORKtirpvU7WlvGSOFwKbd5yxM0oZh5ZneR2oXL/4lre
fP+jQAuAAftfMzvo4EjR/6DaHpg+YWMJMM0sncu6FwFLo0V1l8gdaiPiWRZXkTVq
aujZg9ECgYEA5Xkw2rBMWyLYVm+DgjZ2mhbRop2lWrjGKh8CYFuHXP1C1TRvUsGA
zpNyF4Gz9OAPsUm7JoG3dChr2+/or2UGrhD2BuSDPz9XIhQkQ+SOuBKTV3EcZVDz
BKajm7M+EkdVQdD8Rv5gKTHlTNtGSK+WxmSbjobCVZtjlmWDUm7DwykCgYEAvcrg
pKh20H3iLSZY+6GlngvyXe7fT6gj5t5hylHOBkwAZnlgSoRxjNWkYBsm6lCpWGvS
zYNmgxo2KyjsH59P25gyTzNOIgGpabvK+3qkiO/rDErHMM3K+/PCvYI9Ggc6idWa
p0LJniG1WD+xJTsGaFKpqXDczGDmIiEFxhBa9M0CgYAOIbyEez74jdjM2ek7Z6c+
LhGS9ipsv9xUU7yNupVHgMFQ5/3DFu+byTDJic9PUU0mGehQosRtft/Fl6y4wHv8
1EaSfhgnGPuAucTR+Y1ggKRaSjj5dFbC/pAs0okMDyCNARXIOXoqj0wTw508dLPQ
W/nIeTwWkY88f9vqg6/CoQKBgG/NKRQWIRekcC4EnvpsOLGne/iVlHrKI4wGiDi0
g9b1wm6bJXwAFRvPZmsu03fIWFm7+owR0bt9H1fBXYcrQ9GqEEjTgj1KGVAtzd7i
WjZIjn/JNRmswNw2tgsIw5GnnHZBnD7Xewlp9fesXV//K0EdINCtqYPDuQ11wn7w
d4QpAoGBAJoESzi2a+kQhIoqF+sdCWRXmtieUBvQMFqoIrIYuWMHmbUBewTByRzJ
2LAet1kkPQEScWX3OifuzScuQ2E+UB6q4JFqie+VjFItJU5OE4/45nf6IYyVBxwj
TcZR1bO+Rx1eFnj0Xyhq4Zy9iuGzJhZxpzD7P+LJG9t3rlAkOIyL
-----END RSA PRIVATE KEY-----`
const decryptedWithCrypto = privateDecrypt (
{ key: privateKeyPem, padding: constants.RSA_PKCS1_PADDING },
Buffer.from(encryptedRandomBits, 'base64')
)
const nodePrivateKey = forge.pki.privateKeyFromPem(privateKeyPem) as forge.pki.rsa.PrivateKey
const padding = Buffer.alloc(1)
padding.writeUInt8(0,0)
const padded = Buffer.concat( [ padding, Buffer.from(encryptedRandomBits, 'base64') ])
//node-forge cannot decrypt without the padding!
const decryptedFromPaddedWithNodeForge: string = nodePrivateKey.decrypt(forge.util.decode64(padded.toString('base64')))
const decryptedFromPaddedWithCrypto = privateDecrypt (
{ key: privateKeyPem, padding: constants.RSA_PKCS1_PADDING }, padded
)
expect(btoa(decryptedFromPaddedWithNodeForge)).toEqual(decryptedWithCrypto.toString('base64'))
expect(btoa(decryptedFromPaddedWithNodeForge)).toEqual(decryptedFromPaddedWithCrypto.toString('base64'))
done()
})
I'm able to connect to the postgres instance via pgAdmin with the same credentials but I can't connect from my node.js server. I'm running the latest node version installed via Homebrew on my mac.
import { Client } from 'pg'
const config = {
user,
host,
database: DATABASE,
password,
port: 5432,
ssl: {
rejectUnauthorized: false,
key: fs.readFileSync('./certs/postgresql.key').toString(),
cert: fs.readFileSync('./certs/postgresql.crt').toString(),
};
}
const client = new Client(config)
client.connect((err) => {
if (err) {
throw err;
}
});
This is the error I get when calling connect:
Error: write EPROTO 4499043776:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1929:
I tried connecting to the host via openssl with the following command and it seems to connect.
openssl s_client -starttls postgres -connect <ip>:5432
...
Peer signing digest: MD5-SHA1
Peer signature type: RSA
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 4437 bytes and written 511 bytes
Verification error: self signed certificate in certificate chain
---
New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 67F98918A51486780EE40B6F2430310A04CBE141AEC7A78C09EAAC1B6AD62E52
Session-ID-ctx:
Master-Key: C296DD7EAD31580A7D1B3688DA170C3861F5F35755F93BC2A90CACAD7C640B761764C446797475892D785B6A37D278EE
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket:
0000 - c8 c2 49 99 40 4b ed f7-e2 d5 61 6d 3d dc 3a 15 ..I.#K....am=.:.
0010 - 80 b8 31 c8 9a e0 cd 2c-57 90 5a ed 10 aa 3a c7 ..1....,W.Z...:.
0020 - eb 61 59 c4 d8 b0 ab 05-16 f5 b7 35 42 dc e8 d5 .aY........5B...
0030 - c9 06 38 b6 e9 fd 81 bd-ad bc 56 30 e2 92 a7 89 ..8.......V0....
0040 - a6 30 0b bc 71 a7 3d 63-90 ec fc f0 b2 ca 3f 0a .0..q.=c......?.
0050 - 44 4c 57 b3 9f 0c 7f 05-3a 78 6d 90 bc 37 3d 17 DLW.....:xm..7=.
0060 - a4 0b 53 25 c4 d6 88 4b-a1 f2 57 31 07 21 bf 78 ..S%...K..W1.!.x
0070 - 14 b3 93 60 a6 e9 ba 16-0e 48 d1 42 4e 8a e9 83 ...`.....H.BN...
0080 - 53 c0 fe 7e 65 29 e4 e6-02 81 39 aa 3d 3e 0a 9b S..~e)....9.=>..
0090 - c2 a9 17 5a 34 c8 21 3c-9c 96 44 84 d1 48 c8 21 ...Z4.!<..D..H.!
Start Time: 1582830738
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: no
---
I think the issue is that the only protocol the server supports is TLSv1 so the unsupported protocol error was stemming from the client code attempting to use something else newer not something that was too old.
I needed to use secureOptions in the ssl portion of the config to force it to TLSv1.
const config = {
user,
host,
database: DATABASE,
password,
port: 5432,
ssl: {
rejectUnauthorized: false,
key: fs.readFileSync('./certs/postgresql.key').toString(),
cert: fs.readFileSync('./certs/postgresql.crt').toString(),
secureOptions: constants.SSL_OP_NO_TLSv1_1 | constants.SSL_OP_NO_TLSv1_2 | constants.SSL_OP_NO_SSLv2 | constants.SSL_OP_NO_SSLv3,
};
}
I have a domain http://careers.newable.co.uk. I force users to use a secure connection by specifying the all traffic should be redirected over https using the following rewrite rule:
# Redirect http:// to https://
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
However, I have a complication:
A user can go to http://www.careers.newable.co.uk and the users receives a browser error saying: This site can’t provide a secure connection.
I've seen a few .htaccess rules for redirecting such as this:
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
But this has no effect as the browser still complains about the lack of a secure connection.
Tested in chrome:
http://careers.newable.co.uk -> https ok (wildcard certificate *.newable.co.uk)
http://www.careers.newable.co.uk -> https ERR_SSL_PROTOCOL_ERROR
(EDIT2: run wget from debian)
(EDIT3: fix getting openssl certificate)
me#debian:~$ wget careers.newable.co.uk
--2019-01-26 23:36:14-- http://careers.newable.co.uk/
Resolving careers.newable.co.uk (careers.newable.co.uk)... 217.160.0.82, 2001:8d8:100f:f000::2f3
Connecting to careers.newable.co.uk (careers.newable.co.uk)|217.160.0.82|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://careers.newable.co.uk/ [following]
--2019-01-26 23:36:14-- https://careers.newable.co.uk/
Connecting to careers.newable.co.uk (careers.newable.co.uk)|217.160.0.82|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html [ <=> ] 22.54K --.-KB/s in 0.02s
2019-01-26 23:36:14 (1.42 MB/s) - ‘index.html’ saved [23083]
me#debian:~$ wget www.careers.newable.co.uk
--2019-01-26 23:36:27-- http://www.careers.newable.co.uk/
Resolving www.careers.newable.co.uk (www.careers.newable.co.uk)... 217.160.0.82, 2001:8d8:100f:f000::2f3
Connecting to www.careers.newable.co.uk (www.careers.newable.co.uk)|217.160.0.82|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.careers.newable.co.uk/ [following]
--2019-01-26 23:36:28-- https://www.careers.newable.co.uk/
Connecting to www.careers.newable.co.uk (www.careers.newable.co.uk)|217.160.0.82|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [80]: Internal error
Unable to establish SSL connection.
me#debian:~$ openssl s_client -connect careers.newable.co.uk:443 -servername careers.newable.co.uk
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
verify return:1
depth=0 CN = *.newable.co.uk
verify return:1
---
Certificate chain
0 s:/CN=*.newable.co.uk
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFuDCCBKCgAwIBAgIQB1+12liS8q4ucvnaL6vgzDANBgkqhkiG9w0BAQsFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRHZW9UcnVzdCBSU0EgQ0EgMjAxODAe
Fw0xODA2MDgwMDAwMDBaFw0xOTA2MDgxMjAwMDBaMBoxGDAWBgNVBAMMDyoubmV3
YWJsZS5jby51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALwnjijw
iueOu6okNyLQseCeTrwE3n95Qut+gsdZ1asS31cGyYcBlP1d/4H/EH+e1Q1CAXIQ
P8yrdG9LBMOATIEpPXtS6eWrOUmOPwdY/9SrUsqfg5bWLh7z8cvtysm6lhvqgz/r
0VZ9CkyEH8tEVHlyBFafWoQ2or75/y669lDOoK9oT7nxMqCXD67V/cO5WVBZRb1V
TsQ5s7kxpGNvNeqghI/4QJglryLhsvcaFZdHMq+CWWrjL1luH+0SolMpk7VEUKTJ
OlZoEj+HLZ+XXXVMaea2fZIeVYXatOFyXE+QqvDczo3pHMj6LsLzYb17YrK/s7Sp
OiaDWoFcxhWjvEMCAwEAAaOCArQwggKwMB8GA1UdIwQYMBaAFJBY/7CcdahRVHex
7fKjQxY4nmzFMB0GA1UdDgQWBBRjlHhDIDD0QOEgd5gbmyuP28ddujApBgNVHREE
IjAggg8qLm5ld2FibGUuY28udWuCDW5ld2FibGUuY28udWswDgYDVR0PAQH/BAQD
AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjA+BgNVHR8ENzA1MDOg
MaAvhi1odHRwOi8vY2RwLmdlb3RydXN0LmNvbS9HZW9UcnVzdFJTQUNBMjAxOC5j
cmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwBAgEwdQYIKwYBBQUHAQEEaTBn
MCYGCCsGAQUFBzABhhpodHRwOi8vc3RhdHVzLmdlb3RydXN0LmNvbTA9BggrBgEF
BQcwAoYxaHR0cDovL2NhY2VydHMuZ2VvdHJ1c3QuY29tL0dlb1RydXN0UlNBQ0Ey
MDE4LmNydDAJBgNVHRMEAjAAMIIBAgYKKwYBBAHWeQIEAgSB8wSB8ADuAHUApLkJ
kLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN3BAAAAFj33hNlAAABAMARjBEAiA4
7bSmNyjpbzu1w5bl1wmM59iJ3ra+2K2fC3ht8ojQNAIgCnYd2wsGyfkjHUZOmHYk
O4mOJ0HLWTV69N4h+kkQG30AdQCHdb/nWXz4jEOZX73zbv9WjUdWNv9KtWDBtOr/
XqCDDwAAAWPfeE5TAAAEAwBGMEQCIFmaySX1U63uCXCfXumEmlu3U+1SNoMPws0D
Roa1tq14AiBkHrY5RAFJemSow3hWU8SuGFZP31tWA+GpBHUko5aywjANBgkqhkiG
9w0BAQsFAAOCAQEAoiC0i9g1qEHPYUVx/c1bnMfPdMdVbwiOTefo6AQG1oj1WH/6
S5KkhN8LniXBKiVJeK6HPxrSj3ScwVqEySzT4UK/qtfFuo3nhyc703frnZ403EeT
wCKluP30KpqQnaWYaM5eER1S4VrmKw0sPePaj5aNpBQsIDvz8t+2yOJdzelGenQs
7BtDgquQ4FC0GPAZd6YIkxdKkb4JU95VRW9FFcStpeOpZId+9KvdjUtgcnrFpyc6
7ETHAR58c+bSyUvmIozSjMtnMGZm3UkygXSo5Vsb6GRnJLDKTFBxBHQK1+lyonnn
CHzwmKWV7SBQon9dBSrtvZJp4MFcS+4wfSWt0Q==
-----END CERTIFICATE-----
subject=/CN=*.newable.co.uk
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=GeoTrust RSA CA 2018
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3340 bytes and written 332 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: E52F94F0D9AC068747F883CAC856DABB91F33373267FF0A51B12CF624ED8CB51
Session-ID-ctx:
Master-Key: 945F32F3AEA441AD9A610BA479A466817AC680AC6B9A3B0159B87FBA8A5371F1ACF6BE520073B85CE6AD3AAD0B89BC37
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1f 82 a5 15 da 37 a1 28-a4 f9 57 5c 64 c0 76 89 .....7.(..W\d.v.
0010 - c1 8a 4f ed 1a c2 ab 90-fd a8 43 3f e7 c4 3d 5c ..O.......C?..=\
0020 - 98 22 07 fa 57 9d 18 cb-cd bb 0c 30 6a 21 1f fb ."..W......0j!..
0030 - 5b 02 3d 25 88 09 70 ba-b6 bc 71 ae 1f c4 7e e3 [.=%..p...q...~.
0040 - 5f 85 8b 42 db cf 5d 8a-d2 45 51 6f 88 b5 95 19 _..B..]..EQo....
0050 - 23 bf 3a 32 9c 3c 83 3d-e8 5c 48 45 57 ba 1b 72 #.:2.<.=.\HEW..r
0060 - 00 10 5c 42 e5 fc 2f a0-5e 9f ed 75 09 e7 a7 bd ..\B../.^..u....
0070 - 8a d9 ef 39 b3 f9 c2 38-4e c5 db 6a fb c7 8d 1c ...9...8N..j....
0080 - 79 cb e4 0f 35 82 29 a9-7a a1 29 4b 98 55 00 f2 y...5.).z.)K.U..
0090 - bf c7 76 fa 29 a1 e8 45-3c c6 ec 92 d7 e3 30 e3 ..v.)..E<.....0.
00a0 - 3d 68 79 5d 71 28 a7 d4-ed f9 83 3f 36 04 88 95 =hy]q(.....?6...
00b0 - 72 98 7d b9 ba 04 44 b1-63 4f 21 4e b7 3a b9 65 r.}...D.cO!N.:.e
00c0 - 71 2a d3 1c f9 cc 38 84-7a 4b 85 1b 13 22 8b 8b q*....8.zK..."..
Start Time: 1548543090
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
closed
Redirection works as expected. It seems SSL is misconfigured/not configured for www.careers.newable.co.uk. Maybe you only need to set ServerAlias www.careers.newable.co.uk in the <VirtualHost> section where port 443 is defined.
This is not a duplicate issue I have read through all of this and this and more.
I have setup a ELB on amazon to test IPN from IPN Simulator
Then I have verified SSL certificates:
openssl s_client -connect payments-staging.******.com:443
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.buddybid.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFUjCCBDqgAwIBAgIRAI7nMZkTNqCW0STxQGmb53IwDQYJKoZIhvcNAQELBQAw
gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTYwNAYD
VQQDEy1DT01PRE8gUlNBIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIg
Q0EwHhcNMTUwOTA5MDAwMDAwWhcNMTgwOTE2MjM1OTU5WjBbMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxHTAbBgNVBAsTFFBvc2l0aXZlU1NMIFdp
bGRjYXJkMRcwFQYDVQQDDA4qLmJ1ZGR5YmlkLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMKlbACSONR9yst31OlO6sqW+7Zxni6Upk8vnezLFNuE
NUsFsKA7fCC78dsTqaGqeBcigSci4gqupiN0W8oowtd13W047UX7O9HqP+jHcpWR
eJpPwu4y0Xa5pch6ij4E2UIYYCqXtda3UPgCfijbEo4E5m81TxWOzDdO7Q6l9+jS
3BwhNJ9Yvz+eJFLFXGRp1NHVtJcE+bjeUc/WgoPPwgwqTwALFQd4zFWa4cKOwVZt
K8VNmpp8GzjOO8qfzFHMOs1DBHheMXapUP9Ex8LjAxhGQ3A0SNHxFLci5MNaEva9
/pWfWdHY9BX8Zzv8WssBka0QPkpyIMnz/v9Yd+0KVoECAwEAAaOCAdkwggHVMB8G
A1UdIwQYMBaAFJCvajqUWgvYkOoSVnPfQ7Q6KNrnMB0GA1UdDgQWBBRfNZIBvFGB
4po2YikL8kqnAO3ulzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6BgsrBgEEAbIx
AQICBzArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQ
UzAIBgZngQwBAgEwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNy
bDCBhQYIKwYBBQUHAQEEeTB3ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LmNvbW9k
b2NhLmNvbS9DT01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0Eu
Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJwYDVR0R
BCAwHoIOKi5idWRkeWJpZC5jb22CDGJ1ZGR5YmlkLmNvbTANBgkqhkiG9w0BAQsF
AAOCAQEAai/pz2pChZ2QU+rSU7jk8VQcObZW0zkBF+H9QN6caE0NdgyT3wZTv7D+
jjTGg/goZtSBmF59iW2cOCR61/Ct7riEvinOuq7ICvC3r80JfZW3adRE3Q0G0Nku
xDDtXlbonwr78YTt6XH6IjKE+EIwrlcS5zLn6R7KQGSkSbAK2ndd/rCySge0iryd
meUxh7VNUdCXVWaD5JFY1o9ZP4ZgyuD1IWuJfD02BykMeHfRuzKRYe4VEn5soWyV
LO6BKcdAf7vOJ/gcsoxAzGL3I2W7J6ojHpXbc70JEd2h/HjPnGklu+FRx0E+OnHL
oKgf7h/T+jjKypGcyfqrYosUHwkLfg==
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.*****.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6059 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 7490AFBBC42CF60A6B44D760A2FB977D768D13DB78515D0C54081E979397E47D
Session-ID-ctx:
Master-Key: 583A2D57EF3339B97E37E17CFA0E3A17173FF3B3BB97231477ACDD97D2CC02886A6B04B21DC3109E5B4BE0913ED79145
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 90 4a 48 33 b9 ff 8a 5c-a9 cd 2a 79 89 38 7b 7c .JH3...\..*y.8{|
0010 - 91 62 72 de 8f 1e 57 b3-98 99 70 69 35 96 a7 f8 .br...W...pi5...
0020 - c5 26 1b eb 59 75 63 9c-c6 1b b4 be 91 5f a0 70 .&..Yuc......_.p
0030 - fd 6e c4 fc 6e 25 7d d7-7d 51 9f 5e 22 03 1a 91 .n..n%}.}Q.^"...
0040 - a2 ec 42 73 48 e4 e4 70-5d 1a 10 b9 38 d3 60 c9 ..BsH..p]...8.`.
0050 - 9e 42 47 d4 02 dc a5 91-75 c6 b8 80 27 32 ce 52 .BG.....u...'2.R
0060 - 26 85 56 eb 46 d5 a2 be-a9 1e 74 17 05 84 b0 fb &.V.F.....t.....
0070 - cb 34 06 b4 02 d7 a3 0b-76 21 78 c8 2d b3 e3 6a .4......v!x.-..j
0080 - 7e 57 52 7e d7 32 6d 76-0c 50 00 bd 79 aa 3a e3 ~WR~.2mv.P..y.:.
0090 - 20 7d 27 96 97 d9 ea 3d-67 54 b9 f4 bf d8 f2 b6 }'....=gT......
Start Time: 1453929662
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
closed
Then I went and validated ciphers/security via ssllabs.com with this results (A) is sent.
and yet no IPN
I have spent 2 days on this issue and really would appreciate if someone can shine some light on this. Very frustrating and funny enough PayPal using stackoverflow as their ticketing system which I find really lame as I can't expose here business information.
I'm sure there are must be a lot of people out there who has the same issue.