root
/
openssl
mirror of https://github.com/openssl/openssl.git
1
0
Fork 0
Code Issues Actions 7 Packages Projects Releases Wiki Activity
openssl/apps/server.pem

48 lines
2.8 KiB
Plaintext
Raw Normal View History

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-----