openssl/apps/server.pem

Replace expired test server and client certificates with new ones. 2011-12-08 22:44:05 +08:00			`-----BEGIN CERTIFICATE-----`
Replace apps/server.pem with certificate with a sha256 signature. It replaces apps/server.pem that used a sha1 signature with a copy of test/certs/servercert.pem that is uses sha256. This caused the dtlstest to start failing. It's testing connection sbetween a dtls client and server. In particular it was checking that if we drop a record that the handshake recovers and still completes successfully. The test iterates a number of times. The first time through it drops the first record. The second time it drops the second one, and so on. In order to do this it has a hard-coded value for the expected number of records it should see in a handshake. That's ok because we completely control both sides of the handshake and know what records we expect to see. Small changes in message size would be tolerated because that is unlikely to have an impact on the number of records. Larger changes in message size however could increase or decrease the number of records and hence cause the test to fail. This particular test uses a mem bio which doesn't have all the CTRLs that the dgram BIO has. When we are using a dgram BIO we query that BIO to determine the MTU size. The smaller the MTU the more fragmented handshakes become. Since the mem BIO doesn't report an MTU we use a rather small default value and get quite a lot of records in our handshake. This has the tendency to increase the likelihood of the number of records changing in the test if the message size changes. It so happens that the new server certificate is smaller than the old one. AFAICT this is probably because the DNs for the Subject and Issuer are significantly shorter than previously. The result is that the number of records used to transmit the Certificate message is one less than it was before. This actually has a knock on impact for subsequent messages and how we fragment them resulting in one less ServerKeyExchange record too (the actual size of the ServerKeyExchange message hasn't changed, but where in that message it gets fragmented has). In total the number of records used in the handshake has decreased by 2 with the new server.pem file. Reviewed-by: Paul Dale <paul.dale@oracle.com> GH: #10784 2020-01-12 23:44:01 +08:00			`MIIDJTCCAg2gAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdSb290`
			`IENBMCAXDTE2MDExNDIyMjk0NloYDzIxMTYwMTE1MjIyOTQ2WjAZMRcwFQYDVQQD`
			`DA5zZXJ2ZXIuZXhhbXBsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB`
			`ANVdYGrf/GHuSKqMEUhDpW22Ul2qmEmxYZI1sfw6BCUMbXn/tNXJ6VwcO+Crs7h9`
			`o95tveDd11q/FEcRQl6mgtBhwX/dE0bmCYUHDvLU/Bpk0gqtIKsga5bwrczEGVNV`
			`3AEdpLPvirRJU12KBRzx3OFEv8XX4ncZV1yXC3XuiENxD8pswbSyUKd3RmxYDxG/`
			`8XYkWq45QrdRZynh0FUwbxfkkeqt+CjCQ2+iZKn7nZiSYkg+6w1PgkqK/z9y7pa1`
			`rqHBmLrvfZB1bf9aUp6r9cB+0IdD24UHBw99OHr90dPuZR3T6jlqhzfuStPgDW71`
			`cKzCvfFu85KVXqnwoWWVk40CAwEAAaN9MHswHQYDVR0OBBYEFMDnhL/oWSczELBS`
			`T1FSLwbWwHrNMB8GA1UdIwQYMBaAFHB/Lq6DaFmYBCMqzes+F80k3QFJMAkGA1Ud`
			`EwQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwGQYDVR0RBBIwEIIOc2VydmVyLmV4`
			`YW1wbGUwDQYJKoZIhvcNAQELBQADggEBAHvTBEN1ig8RrsT716Ginv4gGNX0LzGI`
			`RrZ1jO7lm5emuaPNYJpGw0iX5Zdo91qGNXPZaZ75X3S55pQTActq3OPEBOll2pyk`
			`iyjz+Zp/v5cfRZLlBbFW5gv2R94eibYr4U3fSn4B0yPcl4xH/l/HzJhGDsSDW8qK`
			`8VIJvmvsPwmL0JMCv+FR59F+NFYZdND/KCXet59WUpF9ICmFCoBEX3EyJXEPwhbi`
			`X2sdPzJbCjx0HLli8e0HUKNttLQxCsBTRGo6iISLLamwN47mGDa9miBADwGSiz2q`
			`YeeuLO02zToHhnQ6KbPXOrQAqcL1kngO4g+j/ru+4AZThFkdkGnltvk=`
Import of old SSLeay release: SSLeay 0.8.1b 1998-12-21 18:52:47 +08:00			`-----END CERTIFICATE-----`
Replace apps/server.pem with certificate with a sha256 signature. It replaces apps/server.pem that used a sha1 signature with a copy of test/certs/servercert.pem that is uses sha256. This caused the dtlstest to start failing. It's testing connection sbetween a dtls client and server. In particular it was checking that if we drop a record that the handshake recovers and still completes successfully. The test iterates a number of times. The first time through it drops the first record. The second time it drops the second one, and so on. In order to do this it has a hard-coded value for the expected number of records it should see in a handshake. That's ok because we completely control both sides of the handshake and know what records we expect to see. Small changes in message size would be tolerated because that is unlikely to have an impact on the number of records. Larger changes in message size however could increase or decrease the number of records and hence cause the test to fail. This particular test uses a mem bio which doesn't have all the CTRLs that the dgram BIO has. When we are using a dgram BIO we query that BIO to determine the MTU size. The smaller the MTU the more fragmented handshakes become. Since the mem BIO doesn't report an MTU we use a rather small default value and get quite a lot of records in our handshake. This has the tendency to increase the likelihood of the number of records changing in the test if the message size changes. It so happens that the new server certificate is smaller than the old one. AFAICT this is probably because the DNs for the Subject and Issuer are significantly shorter than previously. The result is that the number of records used to transmit the Certificate message is one less than it was before. This actually has a knock on impact for subsequent messages and how we fragment them resulting in one less ServerKeyExchange record too (the actual size of the ServerKeyExchange message hasn't changed, but where in that message it gets fragmented has). In total the number of records used in the handshake has decreased by 2 with the new server.pem file. Reviewed-by: Paul Dale <paul.dale@oracle.com> GH: #10784 2020-01-12 23:44:01 +08:00			`-----BEGIN PRIVATE KEY-----`
			`MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDVXWBq3/xh7kiq`
			`jBFIQ6VttlJdqphJsWGSNbH8OgQlDG15/7TVyelcHDvgq7O4faPebb3g3ddavxRH`
			`EUJepoLQYcF/3RNG5gmFBw7y1PwaZNIKrSCrIGuW8K3MxBlTVdwBHaSz74q0SVNd`
			`igUc8dzhRL/F1+J3GVdclwt17ohDcQ/KbMG0slCnd0ZsWA8Rv/F2JFquOUK3UWcp`
			`4dBVMG8X5JHqrfgowkNvomSp+52YkmJIPusNT4JKiv8/cu6Wta6hwZi6732QdW3/`
			`WlKeq/XAftCHQ9uFBwcPfTh6/dHT7mUd0+o5aoc37krT4A1u9XCswr3xbvOSlV6p`
			`8KFllZONAgMBAAECggEADLTt7A+A2Vg2jamf0dztejY0e42QWjstI2b9PZc67fXq`
			`gyx+WYkX07t+uWegYWliG/oPJ9guXiIpE/5sJHToL37S5kmFP2CtynVcJ4wVo4DD`
			`nY0n9+kLX0bgIuS+2V6wpoRcbbbjXM9NHrH8kfe5ftT4UtEDlLI2qLX6IcDd7p4u`
			`OYjILChR8GSGTw96yIy2Ws/1Uq9PMw64JoT4RcK5QqnkcPMDFRH1SeLOL+zXP2c4`
			`nEl9yOy3HauZKxwl/Ry/XK1s3DdjopIAU29ut+hAuMiTb06kzZnumL9NoplKoZtU`
			`otw/gVcCKhT+Ep+p6i8InLF0XEME8A0qUR0niWebgQKBgQD6vkxR49B8ZZQrzjw4`
			`XKs1lI9cP7cgPiuWlDHMNjYou3WbOaGrMeScvbB1Ldh9A8pjAhxlw8AaV/xs4qcA`
			`trmVmSISVMVyc1wSGlJXWi2nUzTNs9OE3vj22SyStihf8UUZtWwX2b5Y4JrYhA/V`
			`+ThGGqHR03oLNLShNLtJc2c7YQKBgQDZ1nkibEyrepexw/fnwkw61IJKq9wRIh1G`
			`PREakhbe9wU5ie0knuf9razt7awzQiwFmlixmWqsM7UEtLuXNnNPciwdrKhhbvrd`
			`vD/rkbIEHEPllIhFlDtOzn3hRBWTzWmXFjpou/2LvHTSbVis4IYVZymTp2jb1ZLs`
			`7VbiG9JTrQKBgQDc6n75g1szzpdehQT/r33U5j/syeJBUSU8NPMu9fB/sLHsgjlT`
			`SNEf2+y1QSBE/Or6kmiMrIv7advn30W+Vj9qc5HWTsPrk4HiHTjA553jl2alebN5`
			`lK4LZspjtIQcC8mS3goPdXPEgJdM/gWpwzr2YQ6DfOxBJT2j7n64NyoT4QKBgH7/`
			`yx+GhCx1DHtXBPDZFhg2TL+78lEK0oZgk9gp06up2CHzh44SFq6O0oLkTcCUk5Ww`
			`poTkLIy4mJBlzfgahp+KsK2cO46SZS9g0ONFzcMXt33hWpE2Gl2XhUwPpYTF/QlY`
			`rDTjZK5S8Mi9dzVSsNlJi7PJphiEK2R1+nFYRwcBAoGBANWoIG85jpXAOnq/Kcgx`
			`Rl3YivR0Ke6r1tFlP58rT7X3EkiboXyQl5vLIFCAwUte6RGrLl1dy3Qyh80B9ySL`
			`Jx6vj42CK7vgv6A96TuVYhnXTnEI6ZvwAQ2VGaw4BizhjALs/kdSE/og9aSCs3ws`
			`KQypwAFz0tbHxaNag/bSAN0J`
			`-----END PRIVATE KEY-----`